Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!dev!dgis!jkrueger
From: jkrueger@dgis.dtic.dla.mil (Jon)
Newsgroups: comp.databases
Subject: Re: A few "fundamental" questions concerning SQL
Message-ID: <918@dgis.dtic.dla.mil>
Date: 8 Jul 90 05:32:29 GMT
References: <10632@chaph.usc.edu>
Organization: Defense Technical Information Center (DTIC), Alexandria VA
Lines: 91

ajayshah@aludra.usc.edu (Ajay Shah) writes:

>I've tried writing SQL queries and found it to be
>tremendously irritating, mainly because it's nonprocedural.

SQL isn't the problem here.  Query languages are generally
nonprocedural by design; if you don't like it, don't use them.

>Now i'm sure 99% of the programmers of the world prefer
>thinking procedural programming languages over
>nonprocedural ones.

And no one is forcing them to do otherwise.  But if we have
to pay for their lower productivity and live with their bugs,
we may choose to engage that 1% instead.

>I'm also a sufficiently fluent HLL
>programmer to be certain it's more painful generating SQL
>that it would be generating a procedural query language.

Again, no one is forcing you to do otherwise.  But perhaps
you could give us an example here?

>I'm also nearly certain optimising the speed of query would
>be easier with a procedural query language.

Only nearly certain?  Good; it will surprise you what
a good query optimizer will do.

But all these arguments have been heard before.  Last time I heard them
it was that no compiler could beat the power, efficiency, and total
flexibility of assembly language.  Still want to argue that one?

Also remember there's only one true measure of performance, it's the
time from when you put the question until the time you get the answer,
including all time you spend with the computer, whether you call it
programming or waiting for a suboptimal program to complete.  Using
that metric I wouldn't care to race on the side of the custom coders.

>So why is SQL defined the way it is?

Again, SQL isn't the problem here.  You have a problem with
a large set of languages and forms, from query languages to
logic programming.

>Is it supposed to be some kind of standard which imposes
>restrictions on the internal organisation of a RDBMS, so
>that no "real-life" queries would use SQL?  Or is it just a
>rotten way of writing queries which somehow happened to
>become a standard?

Yes, no, yes, and not in the way you mean.  But see above.

>Are there any prominent standards for procedural queries on
>relational databases?

As many as you like  :-)

>Is SQL a portable standard: i.e.,
>can one expect to be able to blindly take a SQL script
>written with one RDB (say, Unify) and make it work with
>another (say, Oracle).

No.

>If so, then does that not reduce
>the major RDB alternatives (Unify, Ingress, Oracle, etc) to
>pretty generic alternatives (they all become SQL engines)?

Different application development, user interface specification,
dialog management, data type definition, database design, security
standards and practices, network and distributed access, database
management, archival and backup, checkpointing and audit, and
maintenance, upgrade, and porting tools distinguish otherwise
identical SQL engines, like unto night is distinguished from day.

>In that case, what is it that differentiates two vendors?

Some supply more and better tools.

>I'd use Unix facilities for file-handling and backups etc,
>anyway, so *if* SQL is totally portable and a 100% standard
>then I wouldn't care about which RDB I used.

You got one file per tuple?  You mind taking the database down
for backups?  You mind not being able to assure recovery?

-- Jon
-- 
Jonathan Krueger    jkrueger@dtic.dla.mil   uunet!dgis!jkrueger
Drop in next time you're in the tri-planet area!