Well, since you can only have finite defect parts of anything stored in a workshop, there should at least be the resolution to let a defect part go into waste management, recycling or disposal of hazardous waste, if that applies. So in the end there will be some resolution related data.
In MSSQL with its pages of data a NULLable field really does not consume disc space while it's null and even if some fields have default values needing bytes you just reserve the space you need in the end anyway.
I would still recommend the one table with all I know about it and summarize the decision is not only about all the attributes belonginng to one entity, but also about how other entities are relating to what group of attributes, so the decision should neither be about belonging to a certain entity=belonging to a certain table, but also about how other entities relate to the data.
In my other more familar to me case, ingredients surely belong to the formula, but have their separate table simply because of multiple ingredients belonging to one formula, their number is one very strong reason for the separation, but also because each single ingredient might have a separate and different vendor etc. Not only do ingredients have their own group of attributes, the also relate to multiple other entities and vice versa.
There is no strict rule of what to separate nor of what to keep together, every single attribute may become important enough to justfy an own table for it or simple enough to put as an attribute of a table you already have.
Deciding for one table, that table should rather be called repair jobs or cases, not defects. Once you call it defects the solution related attributes become data you don't want within the same table, because they are not direct attributes of the defect, they are defect related, like a child or sibling entity (another table) is and that would speak for a separate table.
I'd say just the case of no solution ever would justify a 1:0-1 relation to a solutions table with no related record to begin with, only getting a 1:1 related record when the solution begins, i.e. a repair is scheduled, for example, or a spaare part is ordered. But you could also have the first null fields set to some values. The spare part order could be related to solutions table or to the repairjobs table. It's clear you order a spare part for the repair, you don't order a defect part, that's what I mean about the context, the data does not need the separation to be interpreted correctly, you also don't have two repair finishing dates, everything you have just has one value for the repairjob.
Once you find somthing, which you have multiple of or which might relate to the defect or the solution and you couldn't distinguish it, that would make a separation necessary so you have two different foreign keys pointing to either defects or solutions. Since a foreign key is defined not only by being the primary key of another table but also of which other table, you can have a tag id related to defects and to solutions and they'd be distinguishable.
I could also judge from the point of view on another topic, again about the products database I worked on 17 years. There is QA about products and there is a list of defined QA tests to do with products. I inherited the database 17 years ago having a table per such QA test with test specific columns for certain measurements at certain deadlines past the production date. We split all these very test specific tables into a few tables about what criteria were measured or judged on whioch deadlines and on which samples. This unified the whole QA tests and split the very test specific data into more atomic informations, as you can then bundle that atomic smller single criteria tests to further and other macroscopic tests, the data became far less rigid and you could even have statistics and developments of single criteria measured in different tests, you couldn't only compare results of the same tests, you can noe compare results of the same measurements within tests combining very different groups of test criteria. You can have very individual test plans and yet very informative statistics even cross product type borders, as long as products have common attributes.
What we talk about here in case of the solutions are just head data like who gave the final OK of the repair, nothing differing and needing more or less data to justify one or more separate solution related tables. You may of course have data about the single steps of a repair, but you collect data about the whole repair case in one record halding info about the defect and the repair, I see no need to split that head data. In a car workshop you will have several work items related to a solution, but there is no need to split the solution head data from the defect head data, it's both about the same repair job and it's clear the work items are about the solution and not about creating the defect like the spare part order is not a defect part order.
Bye, Olaf.
![[upsidedown]](/data/assets/smilies/upsidedown.gif "[upsidedown] [upsidedown]")
Not to get too off-topic, but just as some quick background info, even though my label for this forum says "Programmer", I feel like that just barely applies. I'm mostly self-taught with programming. I had one programming class in college ("C for Engineers"), the rest I've tried to learn on my own. So if there are seemingly weird knowledge gaps with me, that could explain it.