Re: OOP real life example (was Re: Why is MySQL more

On 13 Aug 2002, Greg Copeland wrote:

> On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
> > I will revise my opinion the instant someone shows me something that I
> > can't do relationally, or is easy to implement with inheritance, and
> > difficult with relational methods. Now you know what you need to do, and
> > if you have no example, we can drop the whole thing. But I am honestly
> > interested to see just what it is that makes table inheritance so great.
>
> I think here-in is the first problem. You seem to insist that the world
> can only allow for one or the other and that the two approaches are
> mutually exclusive.

No, I don't.

1. If it changes the rules, as it were, that is breaks other
parts of the system, it should go. This is the current state
of the postgres implementation. I'm guessing it's not the state
of the desired implementation, once we figure out what that is.

2. If it's just syntactic sugar, that's livable, so long as
it's quite obvious what it's syntatic sugar for. (In the current
case, it's not.) It's even good if it saves a lot of effort.

3. If it actually allows you to do something you cannot otherwise
do, or allows you to do something very difficult with much
greater ease, it's a good thing and it should stay.

> > Well, assuming we are mapping inheritance back into relational stuff
> > behind the scenes (which it appears to me we are doing now), we can just
> > map back to the relation method I demonstrated earlier of doing what
> > someone wanted to do with table inheritance (child tables contain only
> > foreign key and child-specific data; parent table contains primary key
> > and all parent data) and that will fix the implementation problem.
>
> This is what I imagined the preferred solution would be, however, I'm
> also assuming it would be the more complex to implement *properly*.

I don't think so. Both systems are currently, AFICT, pretty simple
mappings onto the relational system. Once we get the exact details of
table inheritance behaviour hammered out, I will gladly provide the
mapping it's possible to create it.

> > Date, Darwen, _Foundation for Future Database Systems, The
> > Third Manefesto (Second Edition)_. Appendex E.
>
> Is this a book or a paper. I have a paper that I've been reading
> (ack...very, very dry) by these guys of the same name.

It's a book. Apparently the paper is, in comparison, much more lively.
:-) But I find the book good in that, at the very least, it shows the
level to which you have to go to come up with a theoretically solid
basis for something you want to implement.

> So the SQL standard does address table inheritance?

Yes.

> Not that this means I feel that they've done the right thing...but
> what did the specification have to say on the subject? Any online
> references?

I don't have a copy of the spec handy, and have not had time to go and
dig one up. All I got from it was out of the two book references I gave.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC