Re: Why is MySQL more chosen over PostgreSQL?

Curt Sampson wrote:
> On Tue, 6 Aug 2002, Don Baccus wrote:
>
>
>>So again relational theory can solve the problem but at a cost in
>>efficiency.
>
>
> If you're talking about theory, efficiency doesn't come into it.

That's rather the point, isn't it?

In the real world, it does.

> The question is how and whether you can express the constratints
> you need to express.

Have I said anything other than this?

> Note that I am not advocating removing anything that does not fit into
> relational theory but does let us do things more efficiently. We live
> in an imperfect world, after all.
>
> In fact, why don't we split the dicussion into two separate parts:
> relational theory vs. object-oriented theory, and practical use
> with postgres, and never mix the two. Ok?

Because in fact you have advocated removing the OO stuff.

You won't find me suggesting that this feature can't be modelled in
relational theory. AFter all I've got something like a quarter million
lines of code over at OpenACS that proves you can.

However my co-developers and users would've glady accept the decreased
effort in implementation and cleaner source code that the PG OO
extensions offer if the implementation had been more complete.

>>The view would work, but of course you have to define the view. Any
>>time you have to do something manually, even something as simple as to
>>define a view, the chance for casual error is introduced.
>
>
> Theory: views should automatically make themselves as updatable as
> possible, unless expressed otherwise. In fact, relationally, there
> is no difference between a view and a base table; that's only part
> of a storage model, which doesn't come into it in our perfect
> theoretical world.

Whether or not the view is written in such a way that it doesn't need to
be rewritten, dropped and recreated when you change the tables that its
composed of, you *still* need to write that view when you first extend
your type using the table+view model.

That's what I was referring to above. You have to write the view and
get it right (i.e. write the join using the proper key for it and the
base view you're extending).

Writing extra code, no matter how trivial, increases the odds that a
mistake will be made.

You also need to write the proper foreign key and primary key
constraints in the table being used to do the type extension. Of course
this is true of PG's current OO implementation but if it were fixed it
would be one less chore that the programmer needs to remember.

> But anyway, I realized that some of the joins I've shown are
> unnecessary; I've incorrectly implemented, relationally, the inheritance
> model you've shown.

You mean you accidently supported the argument that this approach is,
perhaps, more error prone?

> It could even happen that you will show me something that the relational
> model just doesn't handle, in which case you'll have won the argument.

I haven't *made* that argument. Please stop raising strawmen.

The argument I've made is that even though that you can model PG's OO
features not just relationally but in real-live warts-and-all SQL92,
that doesn't mean they're not useful.

We don't need the binary "integer" type, either. We could just use
"number". Yes, operations on "number" are a bit slower and they often
take more space, but ...

Shall we take a vote :)

--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org