Re: model inherited object
Date: 21 Jun 2006 08:08:53 -0700
Not really, I'm afraid.
> 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.
Chris Date is on record, I think, qualifying precisely this approach as one of "The two Great Blunders" in the OO world.
> 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?
There is none, I'm afraid. Certainly not an elegant one. What you want to do, it seems, is to record a tuple x with an attribute value (e.g. pagecount) that says "this must be the same value as the value that appears in tuple y, whatever that value over there is".
If tuple y is deleted, what would be the value for attribute pagecount in tuple x ?
The relational model does not support such a construct.
SQL databases do not, to the best of my knowledge, support such a
===> If you really want to do this, you're on your own (and you'll have to solve all the problems such as the one I mentioned).
I personally cannot imagine that you really *need* this. Received on Wed Jun 21 2006 - 17:08:53 CEST