Table structure manytomany?

mrenshaw

Registered User.
Local time
Today, 01:29
Joined
May 3, 2002
Messages
27
I am attempting to build a QC parts inspected database and would like an opinion on the structure before I get to deep into it.

This is what I am shooting for, three tables table 1: Part and vendor information. Table 2: parts rejected, reason etc. table 3: parts Accepted w/ deviations, qty etc.

I set up one form and 2 sub forms. The main form has the input fields for part number and vendor information that automatically pulls the information and populates the fields as soon as you type in the part number.

Here is where I am unsure how to do this the proper way. The two sub forms rejected and accepted are for entering the part number, qty and reason one line at a time as a data sheet view. I am trying to populate a field in the two sub forms with the main forms record ID and or PO number when they create a new rejected or accepted record to associate all three tables for future reports. Should I set this up with a manytomany relationship? Any Input would be greatly appreciated.
 
mrenshaw said:
This is what I am shooting for, three tables table 1: Part and vendor information. Table 2: parts rejected, reason etc. table 3: parts Accepted w/ deviations, qty etc.

I'm just heading out the door here but I just want to say that your idea for Table1 is not good.

  • One Table for parts
  • One table for vendors
  • One table for reasons
  • One table for orders - you store the status here (rejected/accepted, etc.)

Do a search on normalisation and the Normal Forms of database design.

Best to get bad practice out of the way before you start - saves time spent on problems in the future.
 
Thanks for the direction! I just needed a little push.
 

Users who are viewing this thread

Back
Top Bottom