Re: model inherited object
Date: Wed, 28 Jun 2006 10:40:38 GMT
> deja_at_2bytes.co.uk wrote: >
>>I have a table which I have previously used for objects of a certain
>>this table has a number of columns representing the properties of the
>>book i.e number of pages, author etc.
>>I want to be able to record an inherited object so for example I will
>>have Book1_v1 and Book1_v2 - the only difference between them being the
>>number of pages and the title. However Book1_v3 might be inherited from
>>Book1_v2 but with a different title only while Book1_v4 might be the
>>same as Book1_v3 but with a different publication date.
>>If I copy the Book1_v1 to a new record for Book1_v2 and change the
>>number of pages, if I then change the author of Book1_v1, it will not
>>be reflected in Book1_v2 (and it would be difficult to do via triggers
>>because you cannot be certain which fields are "overridden").
>>Even if I have a table that says [BookId, version number, property,
>>value] to override any number of properties then I am still going to
>>end up with horrible joins and datatype issues and working my way back
>>from v4 to v1 to get a complete row would be a nightmare.
>>What is the solution?
> > > Hi Phil, > > My suggestion is to use three tables! One for the objects, one for the > attributes and one for the classifier defining the objects and > attributes, > as well as domain values, ie. OBJECTLIST, ATTRIBUTELIST, DOMAIN1LIST, > DOMAIN2LIST, etc.
And how do you propose to declare the integrity constraints to the dbms? Simple foreign key references suddenly require cartwheels and backflips.
I reiterate my earlier observation regarding ignorant cranks. Received on Wed Jun 28 2006 - 12:40:38 CEST