I\'m currently working on a project which should help us with our inventory control as well as our purchases to assembly our final product.
We\'re in the stage of mo
It sounds like you might have two kinds of products. One is the 'atomic' part and the other is the 'compound' end product. I would store those in two separate tables, since they both need different pieces of information.
The CompoundProduct table will need a child table as well that links the part to the end product.
If you like, you can still have an 'abstract' product table that contains all products: parts as well as end products. In this table you can store a code and the name, and it is convenient to have one table of products that can be bought and displayed on an order or invoice. Both the Part table as the CompoundProduct table can then have a product id that is a foreign key to the abstract product table, but is unique in Part and CompoundProduct as well.
So in general, this database scheme is powerful and flexible, but I think it is not complete enough, or maybe too flexible for your want.