Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: 26 Feb 2003 01:13:29 -0800
Message-ID: <e9d83568.0302260113.24ea0e54@posting.google.com>


> Yes. But let me stress that I am not a fan of SQL; as a bag calculus
> it
> is also less elegant then it could have been, to put it mildly.

Can you point to some reference with what you think would be a decent query language? What would be the "ideal" db-language in your view?

>
> >- optimizing efforts will be concentrated on the most used features,
> that
> > being queries without disticnt.
>
> If those queries are the ones that are the most used, then that is
> what the
> users apparently want, and so indeed those should be optimized the
> most.

So the user is always right! Tell me why any user would really want duplicates in the result of his/her query. Just give me _one_ example applicable to a real world situation in an actual program.

Taking the table 'P', having, say 1M rows, what is the meaning of the following query:

select city
  from P

> The optimization of imperative programs is very different from
> optimizing declarative query languages, so such an analogy is
> virtually meaningless to people who actually know a thing or two about
> optimization.

The point here is that the more stuff you have to consider the harder it is to do a good job. "Less is More"!

>Btw. What makes you think that programs with GOTOs are
> hard to optimize? Dijkstra did not mention that as an argument in his
> famous letter.

Am I wrong? Are programs with GOTOs as easy to optimise as programs not using GOTO's, assuming that we don't have any restrictions?

>
> That bags are hard to understand is a myth. I have been teaching SQL
> at university level and below that; there are several things about SQL
> that are hard to explain but bags was not one of them.

I have been using, consulting and teaching SQL since 1988 on a daily basis, and I agree that it is not hard to teach. I just think it could be _easier_. And when you go into making "real" programs with SQL calls you have to have a very clear picture of how the optimiser "thinks" so that you choose the correct way to query. That is far from trivial, and it varies a lot between different DBMS's. Granted things have come better (even Oracle is catching up), I have the feeling that optimising over a cleaner language would have been easier in the first place. This involves also giving the user less "choice".

Best regards,
Lauri Pietarinen Received on Wed Feb 26 2003 - 03:13:29 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US