Re: model inherited object

From: Bob Badour <>
Date: Wed, 28 Jun 2006 10:40:38 GMT
Message-ID: <G0tog.3214$> wrote:

> wrote:

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

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