Re: Dreaming About Redesigning SQL

> -----Original Message-----
> From: Lauri Pietarinen [mailto:lauri(dot)pietarinen(at)atbusiness(dot)com]
> Sent: Sunday, October 19, 2003 1:50 PM
> To: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] 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

This same average programmer will have the same difficulty with a pure,
orthogonal and mathematically rigorous language.

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

I once worked on a telephone customer support system that had 5 million
lines of C++ and 5 million lines of SQL. It was too complex for the
average person to comprehend.

There are always going to be some queries that are too slow. If you put
a key on everything, data modifications will go into the toilet. If you
lack a key on a field required for a filtered query, you will have a
table scan. Hence, there is no free lunch, and there will have to be
compromises. However, due to the exponential expansion of compute
power, the efficiency of SQL is the least of our worries. See this
link, it makes for excellent reading:
http://www.kurzweilai.net/articles/art0134.html?printable=1

> best regards,
> Lauri Pietarinen
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index
> scan if your
> joining column's datatypes do not match
>