At 03:28 PM 5/20/2003 +0300, Marius Popa Adrian wrote:

>Although it may seem a no-brainer today, SQL took some time to get
>established with by no means all vendors subscribing to the notion of a
>common database query language. That, remember, is what SQL was originally
>designed to do - provide set-based query processing - the fact that it was
>soon appreciated that it could be used for other purposes, such as writing
>stored procedures, was a bonus.

I am one of those who was not enamored of SQL when there were still
alternatives. As a language it lacks symmetry - assignments in insert
are done one way, in an update differently - it promotes bad habits
- relying on the order of fields in the stored record with the *
and implicit assignment lists - and has general warts like referencing
context variables before they are defined.

In it's original form, it was completely inappropriate for stored
procedures having no conditional or looping expressions. Unlike
some of the alternatives it requires variable declarations which it
did not support. Note that you can't put any of those extensions
into a query.

>However, by the middle of the decade there was a real sense that new
>versions of the ANSI standard would subsume most of the differences
>between the different versions, and we would actually get a genuine SQL
>standard that was widely deployed and only minimally extended.

Really? I must have been in the bath. Seriously, the fundamental
problem with the SQL standard is that it does not provide any
plausible standard mechanism for passing queries from the client
to the database or passing data back.

>"Who bought a barbecue within seven days of purchasing patio furniture?").

select c.name from customers c
join orders o on c.cust_id = o.cust_id
join orders oh on c.cust_id = oh.cust_id
where o.item = 'patio furniture'
and oh.item = 'barbecue'
and oh.date <= o.date + 7
and oh.date >= o.date - 7

Ok, so it's not select * from customers, but it's not rocket science
either.

>If companies are introducing hundreds of proprietary extensions to SQL has
>it actually gone so far away from the standard that to talk about it as if
>it were a common language is absurd?

No change there.

>The short answer to this question will depend on how you look at it. For
>all practical purposes, we should now be thinking about SQL as a language
>with a standard kernel and potentially unlimited extensions. However, the
>market has a vested interest in making us believe that SQL still remains a
>truly portable language.

Anyone who thinks that is either very naive or completely delusional.
In the absence of jdbc, odbc, or another intermediate transport layer,
I defy you to write even the simplest SQL in a C program that will
run against any two of Oracle, Sybase, and Firebird.

>There are some signs that suppliers are moving away from SQL. In
>particular, it is no longer the only language you can use for writing
>stored procedures. Vendors like Oracle and FirstSQL allow you to use Java
>as an alternative.

But java extended with SQL.

>Yet the language is clearly inadequate, ... in the way that it allows the
>execution of very poorly formed code (which is why database optimisers
>have SQL rewrite capability).
>Arguably this is a good thing - it allows novice programmers to still
>create useful queries - but it leads to bad habits and can hardly be
>considered a sound premise.

Actually, that's one thing I consider a strength and an important part of
the best part of relational databases - the separation of the logical and
physical database representations.


Regards,

Ann