What you have done there is put your database in second normal form (2NF) sort of.
The bottom table of yours is the vendoroffer table I suggested earlier. It links together vendors and the actual tangible plug. This is the relationship of vendors to plugs and in db terms it is a many to many relationship. A plug can have many vendors and a vendor offers many plugs.
In this relationship vendors assign item numbers to the plugs they offer but these are unique to the vendor and should not be included with the actual plug's data.
Now you can have a third table plugs or parts, or whatever, with it's own internal key. In each row you can keep data specific to the actual plug, not specific to any vendor or any cross reference. Maybe what its dimensions are, its amperage, its quality?
Any more relationships to plugs are added to the plugs table with a foreign key to another table. Maybe a manufacturer or a car model. Unless, of course, it is a many-to-many relationship like what happened earlier.
Example con Arte de Ascii! (each box is a table, each entry a column) PK = Primary Key -- FK = Foreign key can you tell why? vendor ------------------- | id [PK] integer |----------\ | name string | | ------------------- | | vendoroffer | ----------------------- | | vendor [FK] integer |<-----/ | plug [FK] integer |<-----\ | serial string | | | price decimal | | ----------------------- | | plug | ---------------------- | | id [PK] integer |-------/ | motor [FK] integer |----------------------> ... | gap float | | ...etc?... | ----------------------
You can find lots of stuff on database normalization and design around the web. about.com's Normalization Basics seems pretty gentle.
In reply to Re^5: Organizing and presenting a cross-reference
by juster
in thread Organizing and presenting a cross-reference
by oko1
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |