Mattias, Your 'blueprint' table looks good. > This where "itemID" corresponds to a item in the master table and the > "componentID" ALSO referes to items in the Master table???
Correct. This allows 'recursive' components. For example, Item 3 contains components 1,3,4 and component 4 is actually made of components 7 & 8. In your 'blueprint' table this would be shown as: itemID componentID 3 1 3 3 3 4 4 7 4 8 > Then I could just do a query for all "componentID"s relating to the itemID, > taken from a query on the master table. Yes, but if components can contain components then you have to do the query RECURSIVELY. This is explained by Jim's post. It is easiest to do in programming code rather than trying to write a select statement to do it all at once. For Example: For item 3: Get all components that make up item 3 Then for each component, see if the components has components... and so on. > I also have suppliers or different items/components, I guess it would be > wise to solve that many<->many relationship > In the same way. > A new table with itemID -> supplierID relations? Yes, often many to many relationships have an intermediate table like this. Regards, Andy -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
