Path: utzoo!attcan!uunet!munnari.oz.au!csc!csc3.anu.oz!ccadfa!ghm
From: ghm@ccadfa.adfa.oz.au (Geoff Miller)
Newsgroups: comp.databases
Subject: Re: A few "fundamental" questions concerning SQL
Message-ID: <1735@ccadfa.adfa.oz.au>
Date: 9 Jul 90 03:53:09 GMT
References: <10632@chaph.usc.edu> <26006@pasteur.Berkeley.EDU>
Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia
Lines: 30

mao@eden (Mike Olson) writes:

>In <10632@chaph.usc.edu>, 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.
>> ...

>the reason that nonprocedural languages are attractive is precisely because
>they *are* nonprocedural.  although i'm not crazy about sql, i do believe that
>nonprocedural query languages are superior to procedural ones for ad-hoc
>relational database access.  programmers can be arbitrarily smart, but there's
>no way that they can generate good query plans as quickly as the query
>optimizer for a good database engine can, from a nonprocedural query spec.

And the non-procedural query language can be used much more easily by a
non-programmer.  Sure, if you know that the same query will be run repeatedly
it may be quicker to implement it in a small program, or simply incorporate
it into a menu-driven system so the user has less chance of getting it wrong,
but there will always be the odd ad-hoc query that you didn't allow for.

I guess most of us who use the net are experienced programmers, so the 
procedural approach comes naturally to us *now*.  What you have to remember
is that there is a growing number of users who are demanding direct access
to their data and are not prepared to wait while their request is filtered
through the programming priesthood.  SQL and similar non-procedural languages
provide a means whereby these users can access their data quickly.

Geoff Miller
ghm@cc.adfa.oz.au