Re: Why is MySQL more chosen over PostgreSQL?

On Thu, 2002-08-08 at 17:57, Curt Sampson wrote:
> On 8 Aug 2002, Hannu Krosing wrote:
> 
> > For me they are _not_ two different models but rather one
> > object-relational model.
> 
> Well, given that we've already demonstrated two rather different ways
> of saying "the same thing," I think we have two models happening here.
> However, feel free to explain your "object-relational model" in more
> detail, including its advantages over the ordinary relational model.

The main difference (in the inheritance part) is that a relation does
not have one fixed set of fields, but can have any additional fields
added in inherited tables and still be part of to the base table as
well.

...

> > The table inheritance _implementation_ in PG is in fact broken in
> > several ways, most notably in  not enforcing uniqueness over all
> > inherited tables and not inheriting other constraints.
> 
> Right. I'm glad we agree on that.
> 
> > But as you often like to emphasize, model and implementation _are_
> > different things.
> 
> Ok. I won't object too much to the model, but let's get rid of this
> severely broken implementation, unless there are some prospects
> for fixing it. How's that?

Actually I am not against ripping out the current broken implementation,
but not before there has been a new, correct model available for at
least two releses, so that people have had time to switch over.

The inheritance model that SQL99 prescribes is more like java's - single
inheritance (so that you have no way of inheriting two primary keys ;) +
LIKE in table definition (in some ways similar to java interfaces)

I see that this could be implemented quite nicely by storing all the
inherited tables in the same page file, in which case primary key would
almost automatically span child relations and indexes on child relations
become partial indexes on the whole thing. There already is some support
for this present (namely tableoid system field stored in every tuple)

> BTW, can someone explain the model for inherited tables here? Is
> it really just as described _The Third Manifesto_, trivial syntactic
> sugar over the relational model?  

It is "just" syntactic sugar, just as VIEW is "just" syntactic sugar for
ON SELECT DO INSTEAD rules.

VIEWs are broken too, in the sense that you can't insert into them
without doing some hard work. 

But guess you would rather see VIEWs "fixed" to be insertable and
updatable, rather than ripped out "because the same thing and more" can
be done using RULEs ;)

> Or is it supposed to offer something
> that the relational model doesn't do very simply?

It is supposed to help programmers express structures that they would
describe as inheritance in an ERD diagramm in SQL without having to do
mental gymnastics each time they go from model to schema.

Having a shorter description is on one hand syntactic sugar, on the
other hand shorter.