Re: model inherited object

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 28 Jun 2006 10:40:38 GMT
Message-ID: <G0tog.3214$pu3.78906_at_ursa-nb00s0.nbnet.nb.ca>


j.andersen.lv_at_gmail.com wrote:

> deja_at_2bytes.co.uk wrote:
> 

>>I have a table which I have previously used for objects of a certain
>>class i.e.
>>
>>book
>>
>>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

Original text of this message