Re: model inherited object
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 21 Jun 2006 21:30:22 GMT
Message-ID: <OTimg.462$pu3.12924_at_ursa-nb00s0.nbnet.nb.ca>
>>post is a crank. That said, I suggest the first step toward a solution
>>might be to avoid the First Great Blunder.
>>deja_at_2bytes.co.uk wrote:
>>
>>
>>>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.
>>>
>>>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?
>>
>>Anyone who tells you they have a solution based on a sketchy newgroup
>>post is a crank. That said, I suggest the first step toward a solution
>>might be to avoid the First Great Blunder.
>
> Received on Wed Jun 21 2006 - 23:30:22 CEST
Date: Wed, 21 Jun 2006 21:30:22 GMT
Message-ID: <OTimg.462$pu3.12924_at_ursa-nb00s0.nbnet.nb.ca>
deja_at_2bytes.co.uk wrote:
> hi bob, > >
>>post is a crank. That said, I suggest the first step toward a solution
>>might be to avoid the First Great Blunder.
> > > I have just started reading about First Great Blunder ie class = table, > row = object is wrong, which is obviously my design. Though I am > somewhat restricted by the current solution, being new to this whole > "Blunder" thing - any pointers on how it would be best to model this > scenario avoiding this blunder.
See my earlier comment regarding cranks. To my knowledge, I am not one of those. Although, I am allegedly a fraud of ambiguous rank.
> Bob Badour wrote: >
>>deja_at_2bytes.co.uk wrote:
>>
>>
>>>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.
>>>
>>>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?
>>
>>Anyone who tells you they have a solution based on a sketchy newgroup
>>post is a crank. That said, I suggest the first step toward a solution
>>might be to avoid the First Great Blunder.
>
> Received on Wed Jun 21 2006 - 23:30:22 CEST