Re: Dreaming About Redesigning SQL

From: Seun Osewa <seunosewa_at_inaira.com>
Date: 8 Oct 2003 04:29:47 -0700
Message-ID: <ba87a3cf.0310080329.7f5a6171_at_posting.google.com>


Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:<fPEgb.63802$IA4.3061832_at_phobos.telenet-ops.be>...
> Seun Osewa wrote:
> > In other words do we have the model, the language, or standardisation
> > to blame/praise for the popularity of the relational model?
>
> Don't forget market domination.
By "standardisation" I really meant something close to market domination.

> No. Procedural query language are a very big no no, because you should
> let the database choose how to optimize the queries and not let the
> users choose some optimizations on assumptions about how they think the
> data is stored.
If procedural languages are so bad for database access, how come all the major database vendors (and now the SQL99 standard) have procedural extensions? Procedural coding is flexible, powerful, although not always the most elegant. There's a line we always have to draw between what should be done procedurally and what should be done declaratively because not everything can be done declaratively and you have to depend on what is included in the database engine.

And personally I think that once you have identified the records you are interested in, through a 'declarative' query which can be optimized by the DBMS, one should be able to manipulate is with relative freedom from a powerful-enough procedural. GROUP BY, AGGREGATE FUNCTIONS, and any further processing or transformation of the raw data are probably not so complicated that they cannot be implemented as _libraries_ callable from the procedural language. And yes, with such libraries the procedural code should be shortened.

So my developing idea is to have:
- A declarative language for indicating which data I am interested in. - A procedural language for working on each record of the SELECTed data: locking, unlocking, updating, creating data that depends on it ...

Does anybody on this list have information about "transactional" languages or anything like that. A procedural language where all your actions have no effect until you "commit" and you can rollback, etc?

Regards,
Seun Osewa
"There are things we do primarily because we think they are fun and might just be useful to someone somewhere sometime ..." Received on Wed Oct 08 2003 - 13:29:47 CEST

Original text of this message