Re: Data Modeling "the third way ?"

In message <f2f59d82.0304111002.616c209e_at_posting.google.com> , John <jbradshaw777_at_yahoo.com> writes
>Andy Hardy <junkmail@[127.0.0.1]> wrote in message
>news:<e9NCFWTNMdl+Ew4d_at_hardyfamily.plus.com>...
>> In message <b515b4da.0304101021.36434d67_at_posting.google.com> , Dario
>> Rossa <dario.rossa_at_mature.be> writes
>>
>> >- No relationships between tables.
>> >- Table A contains in one of the columns the name of the related table
>> >- Table A contains the record number of the related table, mentioned
>> >in the column above.
>>
>> I've worked on something similar in a Bill Of Materials database. The
>> main table contained 'common' attributes, whilst other tables contained
>> the attributes specific to a particular item type. The main table also
>> contained the name of the table in which the specific details were kept
>> and that table would have the same item id as the main table.
>>
>> It was flexible, but you spent quite a bit of time doing double queries
>> to find complete item details that you were interested in.
>>
>> Andy
>
>I cann't quite see it. Can you explain why/how it is flexible? Thanks.
>
>- John

Something like:

Table COMMON
COMM_ID PK
ITEM TYPE e.g. SCREWS, NUTS, WHEELS
NAME
DESCRIPTION
MATERIAL
etc.

Table SCREWS
COMM_ID
LENGTH
THREAD PITCH Table WHEELS
COMM ID
DIAMETER
WIDTH Table BOM Relationships
COMM ID PARENT
COMM ID CHILD
etc.

So you could do a treewalk of the BOM Relationships, find out what the items are from the COMMON table and then go to the other tables to pick out more details.

Andy

-- 
Andy Hardy. PGP ID: 0xA62A4849