Re: OOP real life example (was Re: Why is MySQL more - Mailing list pgsql-hackers

Ok, big bundled up reply here to various people.

> From: Greg Copeland <greg@CopelandConsulting.Net>
>
> > What makes things more confusing is poor understanding of a feature, not
> > the feature itself.
>
> Agreed.  Just because a feature may not be well understood by the masses
> doesn't mean the feature is worthless.

Yeah, but if it's not understood by fairly smart people familiar
with both relational theory and OO programming? If the feature is
confusing because it appears to be something it's not, that's a
feature problem, not a problem with the people trying to understand
it. Maybe all that's necessary to fix it is a terminology change,
but even so....

> Hmmm...there might be.  Curt raises in interesting point below.  Do keep
> in mind that I believe he's specifically referring to table inheritance
> and not the broad scope of "language wide" inheritance.

Yes.

> > All _simple_ inheritance problems are easily solved by simple relational
> > solutions. The general problem of much more typing and debugging, less
> > clues for optimiser etc. are not solved by _simple_ relational
> > solutions.
>
> I agree with Hannu here.  Curt's comment seems like lip service.

Well, as I said: examples please. Quite frankly, between the lack
of a clear model of table inheritance (Hannu seems to have one,
but this needs to be written up in unambiguous form and put into
the postgres manual) and the bugs in the postgres implementation
of table inheritance, I've found the relational model much easier
to use for solving problems.

> From: Oliver Elphick <olly@lfix.co.uk>
>
> On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > How exactly would you create an abstract base class for table type?
>
> CREATE TABLE abstract_base (
>    cols ...,
>    CONSTRAINT "No data allowed in table abstract_base!" CHECK (1 = 0)
> )
>
> This assumes that the constraint is not inherited or can be removed in
> child tables.

Are we then assuming that tuples in the child tables do not appear
in the base table? That's more or less what I'd assumed when I
originally heard about table inheritance (after all, instantiating
a child object does not automatically instantiate a separate copy
of the parent object), but the SQL standard, postgres, and I believe other
systems make the exact opposite assumption.

If the child table tuples do appear in the parent, you've now got
a situation analogous to the current postgres situation where a
constraint on the parent table is an outright lie. (I'm thinking
of the UNIQUE constraint which guarantees that all values in a
column will be unique--and then they aren't.) I consider breaking
the relational model this badly a completely unacceptable cost no
matter what additional functionality you're wanting to add, and I
expect that most other people do, too.

> From: Greg Copeland <greg@CopelandConsulting.Net>
>
> That, in it self, I find rather interesting.  Is there any papers or
> books which offers explanation of how constraints should handled for
> table inheritance?

Here again, I'd love to hear about some references, too. I see a
lot of people saying they like table inheritance; I don't see anyone
(except maybe Hannu) who seems to have a clear idea of how it should
work.

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