Re: Why is MySQL more chosen over PostgreSQL?

On Wed, 2002-07-31 at 04:35, Curt Sampson wrote:
> On 31 Jul 2002, Hannu Krosing wrote:
>
> > I would not rush to drop advanced features, as they may be hard to put
> > back later.
>
> If they are hard to put back, it's generally because the other code
> in the system that relates to it has changed, so you can't just bring
> back what is in the old versions in the CVS repository.
>
> But if the code was left in, that meant that someone had to make all of
> those integration changes you'd have to make to bring the code back;
> it's just they had to make it as they were adding new features and
> whatnot. If in the end you decide that the feature you didn't drop isn't
> important, you just did a lot of work for nothing. You may also slow
> down or stop the implementation of other, more useful features, because
> people find that the work to add them isn't worthwhile, due to having to
> change too much code.
>
> > If they stay in, even in broken form, then there wont be
> > nearly as much patches which make fixing them harder.
>
> Summary: someone always has to do the patches. It's just a question of
> whether you *might* do them *if* you decide to bring the feature back,
> or whether you *will* do them because the feature is there.

Often there are more than one way to do things. And the feature being
there may prompt the implementor to choose in favor of a way which does
not rule out the feature. It does not neccessarily make that harder for
new features, though it may.

> > > What we (or I, anyway) are arguing is that
> > > the relational model does everything that table inheritance does, and at
> > > least as easily.
> >
> > The problem is that 'the relational model' does nothing by itself. It is
> > always the developers/DBAs who have to do things.
>
> Ok. So "the developer can do what table inheritance does just as easily
> in the relational model."
>
> > And at least for some brain shapes it is much more convenient to inherit
> > tables than to (re)factor stuff into several tables to simulate
> > inheritance using the relational model.
>
> I highly doubt that.

I said it is personal ;) Some other brain shapes are more fit to working
in relational model, even when writing front-ends in C++ or java.

> Relating two tables to each other via a key, and joining them together,

It gets more complicated fast when inheritance hierarchies get deeper,
and some info is often lost (or at least not explicitly visible from
schema). That's why advanced modeling tools allow you to model things as
inheritance hierarchies even when they have to map it to relational
model for databases which do not support inheritance.

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.

> allows you to do everything that inheritance allows you to do,
> but also more.

* you can do anything (and more ;) that DOMAINs do without domains.
* And you can do anything and more that can be done in C++ in C.
* And you can do anything sequences do and more without explicit syntax
for sequences (except making them live outside of transactions,
but this is mainly a performance hack and sequences are outside
of relational theory anyway ;)
* And as I already mentioned, you can compute anything on
a Turing Machine (I doubt you can compute more, but it is not
entirely impossible as it has to work 'more' ;)

> 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.

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.

> > > Extending the model adds complexity without adding the
> > > ability to do things you couldn't easily do before. (This, IMHO, makes
> > > table inheritance quite inelegant.)
> >
> > Then explain why SQL99 has included inheritance ?
>
> Becuase SQL has a long, long history of doing things badly.

Or to rephrase it: SQL has a long, long history of doing things (though
badly)

> The language has been non-relational in many ways from the very beginning.

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

> But Codd and Date argue that much better than I do, so I'd prefer you
> read their books and respond to those arguments. I can provide
> references if you need them.

In theory theory and practice are the same, in practice they are often
not nearly so.

From your reference:

|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.

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.

----------------------
Hannu