Solved

database design

Posted on 2016-08-31
10
90 Views
Last Modified: 2016-09-01
Hi Experts,

Here's a fairly simple database design question, but I'd like some input from all y'all experts.

I've got this system where Products need to be tested, and tests are always tied to production Lots, but at times, Tests need to be set up before the Lot_Number is known. In such a case, is it better to put the Product_ID in both the Test and the Lot tables, or only keep it in the Lot table, and leave the Lot_Number null until it is known? (I'm guessing that's the better option, but not sure.)

Thanks!
Steve


Test
------------------------------
Test_ID int
Lot_ID int

Lot
-----------------------------
Lot_ID
Product_ID
Lot_Number
0
Comment
Question by:tablaFreak
  • 3
  • 2
  • 2
  • +3
10 Comments
 
LVL 35

Expert Comment

by:Terry Woods
Comment Utility
In just one place is generally better, as data can't get out of sync (eg a Test where the Product_ID is different to the Product_ID for the associated Lot_ID).
0
 
LVL 45

Expert Comment

by:Vitor Montalvão
Comment Utility
If Lot_ID is not part of the Primary Key then let it to be nullable as you can update it later when you know the Lot number.
0
 
LVL 50

Expert Comment

by:Steve Bink
Comment Utility
What data points do you need for a test, which are not also related to the results of the test?  

If the test is something you need to set up separately from the actual act of testing, perhaps you need to break your table into "tests" and "test_instances".  This is much more efficient if test configurations are meant to be reused on successive lots of the same product, but that is not a requirement.
0
 
LVL 38

Expert Comment

by:Aaron Tomosky
Comment Utility
In this example leave the lot number where it is and have lot Id nullable.

It sounds like you might actually have three tables: testtemplates, lots, and tests that are a template on a lot.
0
 
LVL 51

Assisted Solution

by:Mark Wills
Mark Wills earned 125 total points
Comment Utility
I am inclined to agree with some of the assertions / observations made by Steve and Aaron above.

In so much as you may need further tables.

You say each product must be tested, but I don't really see that specific relationship in your design until you incorporate Lots.

You say that tests need to be set up before production Lots are known.

Implied, but not stated, we can only assume that a Test is likely (or sounds) to be product specific and could be established before the production lot is known.

It sounds like your Production Lots are akin to a "batch" or "job".

So, would like to see something that formalises those immediately identifiable relationships
1) Test
2) Test + Product
3) Product
4) Product + Production Lot

For me, the confusion seems to be in your first table which tries to establish Test + Lot but Lot is not known yet.

That doesn't mean that you can't leave Lot_Number nullable, but it is unknown as to the relationship between Lot_Number and Lot_Id (or the timing of when that relationship is known).

Then as tests are performed, they create the test results and Lot_Number would then be known (so insert the result rather than update the lot_number)

Like the other experts, there seems to be some missing information as to the relationships to give an accurate appraisal of your design....

However, to answer your question "In such a case, is it better to put the Product_ID in both the Test and the Lot tables" I would say a definitive YES given the information provided (and that is before we have to worry about the nullability of lot_number).

Cheers,
Mark
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Author Comment

by:tablaFreak
Comment Utility
Hi Guys,

Thanks for the inputs. Yes, to clarify, not all Products are tested, only some, and in some cases, Tests are set up before Lots are known (as I mentioned), but there are so many variables in the Product formulation that it's rare that a single test configuration/instance is run more than once.

In fact there already is something of a Test Template table, which is called Specification, which is used to generate Test Line Items from a given product specs.  (Maybe irrelevant for what I'm asking). I simplified the model, trying to isolate my issue for this question, but there is a Test_Line_Item table which holds the actual Test Lines, and the Test table contains only the Test metadata. The issue is that I'm averse to storing Product_ID in the Test table as well as the Lot table since it definitely has to be in the Lot table, and I want to avoid the problem Terry pointed out of potential mis-matched Test.Product_ID and Lot.Product_ID. What I'm imagining is that the Lot table would have the Product_ID populated with the Product being tested, so the Test.Lot_ID would refer to the Lot record with a null Lot_Number. The risk there is the user could potentially create a new Lot record for the Lot with a test already tied to it, and inadvertently create orphaned Lot records, or Lots that would need to be merged or resolved. Maybe the best solution is to go ahead and keep Product_ID in both tables, and just make sure there aren't mismatches in the code? This would minimize user error, and leave the validation to the code. Perhaps safer in the long run, but it goes against good database design. Thoughts? Thanks a lot.

- Steve
0
 
LVL 35

Accepted Solution

by:
Terry Woods earned 250 total points
Comment Utility
My feeling is at this point you're beginning to overthink it, and it doesn't matter too much either way. If you're worried about invalid data (and where reliable data is important, this is a big concern), instead put the time into setting up a script that runs regularly and sends an alert if invalid data detected. There might be other queries you could add to that too.
0
 
LVL 38

Assisted Solution

by:Aaron Tomosky
Aaron Tomosky earned 125 total points
Comment Utility
Agreed. The quick and dirty method I've used is to write a " things that should not be" query that looks for inconsistencies. Null tests past a week old, product Ids not existing in two tables, etc...
0
 

Author Comment

by:tablaFreak
Comment Utility
Thanks guys, sounds good.
Best,
Steve
0
 

Author Closing Comment

by:tablaFreak
Comment Utility
thank you
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Database tuning – How to start and what to tune. This question is frequently asked by many people, both online and offline. There is no hard and fast rule-of-thumb for performance tuning, however, before beginning the tuning process one should a…
Many companies are looking to get out of the datacenter business and to services like Microsoft Azure to provide Infrastructure as a Service (IaaS) solutions for legacy client server workloads, rather than continuing to make capital investments in h…
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now