Re: model inherited object
Date: 21 Jun 2006 22:50:44 -0700
> sorry - crossposting (from sqlserver programming) as it's more likely
> to be relevant here
> 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.
I'm not sure if you are really doing version management or inheritence? The two are very different. I'll assume you're wanting version management. (Mind you there are sane, if not perfect, ways to marry OOP and the RM but that's another story).
Can't you just have (bookID, version, validFrom, validTo, otherAttributes...). If validTo is null then that tuple is the latest.
On updates you just have to update the outdated tuple's validTo attribute (set to now) and insert a new tuple (almost a copy) with whatever alterations it has.
I have seen this scheme work, it won't be trivial but it'll work.
> 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").
I would avoid the above. You should never need to change the data in multiple places.
> 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.
I agree that would be a nightmare.
> What is the solution?
I'm not sure I've understand your requirements entirely but if my guesses are correct the scheme I talked about should work for you.
At any rate I strongly encourage you to keep it as simple as possible.
Cheers. Received on Thu Jun 22 2006 - 07:50:44 CEST