Re: model inherited object

From: Cimode <cimode_at_hotmail.com>
Date: 21 Jun 2006 23:00:32 -0700
Message-ID: <1150956032.936244.193490_at_g10g2000cwb.googlegroups.com>


Bob Badour wrote:
> 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.
Your knowledge in mathematics is way too limited to realize you would not be crank and even if it was not, you would to dumb to realize that *crank*, *troll* concepts are total nonsense in rational thinking about people. That attitude makes the essence of a Fraud. That and the tons of examples of idiotic statement expose in the FEW (Fraud Exposal Wall).

> I can offer some pointers to pointers, though. I would suggest Fabian
> Pascal's _Practical Issues in Database Management_ book and
> Date/Darwen/Lorentzos' _Temporal Data and the Relational Model_.
>
> I will warn you that SQL doesn't really support the
> Date/Darwen/Lorentzos proposals for dealing with temporal data, though.
OOOHH what a surprise! Temporal data is a complex issue. Since SQL fails daily in dealing with simple elementary RM issues, what else could be said about time based proposals.

> > 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 Thu Jun 22 2006 - 08:00:32 CEST

Original text of this message