Originally Posted by
Mozencrath
So this DB isn't for placing orders. It'ds for reviewing historical government contracts. To answer, if the gov wants to buy the red chair, it has a completely different NSN than the blue chair. They'll say "we want to buy NSN 1000-01-111-4321 and we will only accept the chairs made by So and So Furniture company (company CAGE code 71122) and their part number is ABC123.
OK, but if the manufacturer uses their own internal identifier for the chair and it is the same number regardless, then what does it matter if you are giving each of those a different part number if the manufacturer does not do that? I think that is the piece that is missing.
The requirement does not seem unlike what I used to deal with at work. There'd be a table of manufacturers, a table of internal (to us) part numbers called RM's and a junction table of RM's to manufacturer because we could get the same RM from more than one supplier. That's fine for things like fasteners or anything else that is common across the supply chain. However, any aspect of the item that distinguished it from another item meant it had a different part number - in our system AND the supplier system. There's no way a 1/2"x3" grade 5 bolt had the same part number as a 1/2"x3" grade 9 bolt. It just doesn't make sense. Nor should a red chair have the same part number as an otherwise identical blue one; not in anyone's system.
To answer the second part of your post I'll say that Excel data almost never fits into a normalized database schema because spreadsheet data is column based and db data should be row based. If the db tables are not properly normalized you will forever have trouble. If that is a new concept to you, it's best that you research db normalization before you worry about how to get data in or out.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.