Re: Why is MySQL more chosen over PostgreSQL? - Mailing list pgsql-hackers

On 31 Jul 2002, Hannu Krosing wrote:

> An it is often easier to map OO languages to OOR database when you dont
> have to change your mindset when going through the interface.

But you have to anyway! Adding this inheritance does not remove the
relational model; it's still there right in front of you, and you still
have to use it. You have simply added another model to keep track of as
well.

And I've done a fair amount of OO lanugage <-> relational database
interfacing, and the problems I've encountered are not helped by
table inheritance. In fact, table inheritance has been irrelevant.
But maybe I missed some problems.

> > allows you to do everything that inheritance allows you to do,
> > but also more.
>
> * And you can do anything and more that can be done in C++ in C.

Ok, this is really starting to annoy me. Can we stop with this argument,
since you *know* it is attacking a straw man?

> > If you have difficulty with keys and
> > joins, well, you really probably want to stop and fix that problem
> > before you do more work on a relational database....
>
> It is of course beneficial to make joins faster, but it is often easier
> to do for more specific cases, when the user has implicitly stated what
> kind of a join he means.

No, my point is, you simply cannot do good work at all on a relational
DB without understanding keys and joins. It does not matter whether
table inheritance is present or not. Therefore everybody effectivly
using a database is going to have enough knowledge to do this stuff
without table inheritance.

> One example of that is the existance of contrib/intagg which is meant to
> make the relational method usable (performance-wise) for a class of
> problems where _pure_ relational way falls down.

You seem to be confusing the relational model with a particular
implementation of a relational database. The relational model handles
this just fine, because the relational model doesn't have performance.

This particular contrib module does not change anything at all
about the relational model as implemented in postgres. It just
provides a particular performance work-around. Note also that the
performance problem can also be fixed in other ways; under MS-SQL server
I'd simply use a clustered index on the one-to-many table.

In fact, given that contrib/intagg works only with relatively static
data, I'm not sure why you'd use it instead of just using the
CLUSTER command once in a while.

> SQL has had pressure to be usable for a broad range of real-world
> problems from the beginning, which theory has not.

SQL is actually much less usable for many real-world problems than
a proper relational language is. But as I said, read Date, and then
argue; I'm not going to spend days rewriting his books here.

> |Date and Darwen's _Foundation for Future Database Systems: the
> |Third Manifesto_ goes into much more detail about how they feel
> |object-oriented stuff should happen in relational databases. Appendix E
> |("Subtables and Supertables") discusses table inheritance. It ends with
> |this statement:
> |
> |    To sum up: It looks as if the whole business of a subtable
> |    inheriting columns from a supertable is nothing but a syntatic
> |    shorthand--not that there is anything wrong with syntatic
> |    shorthands in general, of course, but this particular shorthand
> |    does not seem particularly useful, and in any case it is always
> |    more than adequately supported by the conventional view mechanism.
>
> Which is clearly not true in PostgreSQL's case, as adequate support
> would IMHO mean that the rules for insert/update/delete were generated
> automatically for views as they are for select.

It certainly would be nice if we did that.

> Of course we could go the other way and remove support for VIEW's as
> they can be done using a table and a ON SELECT DO INSTEAD rule.
> Actually this is how they are done.

*Sigh*. You seem to be unable to distinguish between changes to
the conceptual model of a system and changes to implementation
details.

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