Path: utzoo!attcan!uunet!samsung!usc!ucsd!ucbvax!pasteur!eden!mao
From: mao@eden (Mike Olson)
Newsgroups: comp.databases
Subject: Re: A few "fundamental" questions concerning SQL
Summary: sql is your friend
Message-ID: <26006@pasteur.Berkeley.EDU>
Date: 9 Jul 90 01:00:55 GMT
References: <10632@chaph.usc.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@postgres.Berkeley.EDU (Mike Olson)
Followup-To: comp.databases
Organization: University of California, Berkeley
Lines: 42

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.
> ...
> I'm also nearly certain optimising the speed of query would
> be easier with a procedural query language.
> 
> So why is SQL defined the way it is?

this question will generate terabytes of traffic in the newsgroup;
jon kreuger already responded, and presented several points well.  as
an internals type, i have a few things to add.

in order for you to specify a procedural query, you need to know the
layout of data on the disk, and you must be able to deal with all data
types that appear in the data set you're working on.  in addition, any
changes to the information on disk -- what's stored, or how it's stored
-- is going to force you to reformulate your procedural query.

in order for you to specify an efficient procedural query, you need to
know what indices exist on attributes in your tables, how selective they
are, whether there's any ordering in the base tables you can exploit,
whether caching results is likely to prove beneficial given the history
and likely future course of execution, and eighty-seven pounds of other
stuff that you probably don't want to think about.  and if you do think
about it, i can come along fifteen minutes later, add or delete an index,
and send you into a screaming rage as you try to deal with the new schema.

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.

you will probably find that, with practice, formulating queries in sql gets
easier.
					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu