Re: Why is MySQL more chosen over PostgreSQL?

Curt Sampson wrote:
> On Sat, 3 Aug 2002, Sander Steffann wrote:
> 
> 
>>I have this problem in a few real-life cases, so if you have a sollution to
>>this, I would realy appreciate it!
> 
> 
> Add a card_type column to your main table, and insert something
> indicating the value of the card type there.
> 
> That won't stop you from having entries for the card in both
> network_card and sound_card, but one of those entries will be
> meaningless extra data.

So again relational theory can solve the problem but at a cost in 
efficiency.

So could a Turing machine.

> Of course, this also means you have to go back to the relational
> model to select all your network cards. Doing
> 
>     SELECT * FROM network_card
> 
> may also return (incorrectly inserted) non-network cards, if your
> data are not clean, but
> 
>     SELECT card.card_id, card.whatever, network_card.*
>     FROM card, network_card
>     WHERE card.card_id = network_card.card_id
>     AND card.type = 'N'
> 
> is guaranteed to return correct results. And of course you can just
> make that a view called network_card, and the same statement as
> you used with the inerhited table will work.

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.

> Oops, did I just replace your "object-oriented" system with a
> relational one that does everything just as easily, and even does
> something the object-oriented one can't do?

You mean "waste space with meaningless extra data"?

Of *course* you can do that in an object-oriented one.  Your skills 
aren't unique, nor is your skill level though you act as though you 
think you're in a class of your own.

> Sorry about that. :-)

Me, too.  The relational model is extremely powerful but it's not the 
be-all and end-all of all things.

You still haven't answered my earlier observation that the PG model, 
with all its flaws, can reduce the number of joins required.

For instance in your example card and network card need to be joined if 
you want to return network card.  That's what I see in the view.

"FROM card, network_card"

Using PG's inheritance no join is necessary.

I assume you know that because you've demonstrated your brilliance to 
such an extent that I can only assume you've familiarized yourself with 
the actual details of PG's implementation?

I can't imagine you're the kind of mouth-flapper that would do so 
without such basic research, after all.

So ... assuming my assumption is true and that you've bothered to study 
the implementation, why should I prefer the join over the 
faster-executing single-table extraction if I use PG's type extension 
facility?


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