Re: Dreaming About Redesigning SQL

Anthony W. Youngman wrote:

>Well, as far as we MV'ers are concerned, performance IS a problem with
>the relational approach. The attitude (as far as I can tell) with
>relational is to hide the actual DB implementation from the programmers.
>So it is a design "flaw" that it is extremely easy for a programmer to
>do something stupid. And you need a DBA to try and protect the database
>from the programmers!
>
>As soon as a requirement for a database specifies extraction of the
>maximum power from the box, it OUGHT to rule out all the current
>relational databases. MV flattens it for it for performance. As an MV
>programmer, I *KNOW* that I can find any thing I'm looking for (or find
>out it doesn't exist) with just ONE disk seek. A relational programmer
>has to ask the db "does this exist" and hope the db is optimised to be
>able to return the result quickly. To quote the Pick FAQ "SQL optimises
>the easy task of finding stuff in memory. Pick optimises the hard task
>of getting it into memory in the first place".
>
So in your opinion, is the problem

1) SQL is so hard that the average programmer will not know how to use it
efficiently
or
2) Relational (or SQL-) DBMS'es are just too slow

If 2) then why don't we get a bit more concrete. Could you give
an example of a query that in your experience would be too slow using
a standard SQL database (e.g. Oracle, or MySQL). We could then
actually try it out on some machine and compare. I suggest using
the customer-order-order_detail-product database

If 1) I would like to hear some concrete examples.

best regards,
Lauri Pietarinen