Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!ames!amdahl!rtech!llama!jas
From: jas@llama.rtech.UUCP (Jim Shankland)
Newsgroups: comp.databases
Subject: Re: Asynchronous SQL
Message-ID: <5051@rtech.rtech.com>
Date: 19 Mar 90 17:37:33 GMT
References: <2438@ncr-sd.SanDiego.NCR.COM> <745@dgis.dtic.dla.mil> <3510@infmx.UUCP> <779@dgis.dtic.dla.mil> <3585@infmx.UUCP> <4990@rtech.rtech.com> <793@dgis.dtic.dla.mil> <5030@rtech.rtech.com> <5045@rtech.rtech.com>
Sender: news@rtech.rtech.com
Reply-To: jas@llama.rtech.com (Jim Shankland)
Organization: The Eddie Group
Lines: 33

In article <5045@rtech.rtech.com> cmorris@ws2s.UUCP (Colin Morris) writes:
>Why force the applications programmer to reinvent the wheel by
>requiring _him_ to use OS or programming language features to provide the
>asynchronicity? If SQL itself provides an asynchronous interface, such support
>can be provided by the SQL vendor, thus freeing the applications programmer
>from such concerns.

I'm not sure why it's "reinvent[ing] the wheel" for an application programmer
to encode the application's concurrency in, say, Ada, but not in SQL.
And asynchronous SQL is of no help at all in the application that wants
to do concurrent non-database operations.

>Remember, also, that (i) most current programming languages are hardly bastions
>of parallelism, and (ii) application level parallelism often demands a 
>process-rich environment:- don't assume that all broadly used operating systems
>provide such an environment. 

True enough; and asynchronous SQL doesn't exist yet either :-).

It will always be tempting to provide some useful feature in SQL that
may fill a gap on some antiquated application platform.  Such features
are bound to be useful to somebody or other.  The cost is increased
clutter and complexity in SQL.  I'm sure somebody would appreciate having:

	SELECT DNAME, AVG(SALARY) FROM EMP GROUP BY DNAME
		OUTPUT OPTIONS(POSTSCRIPT, BAR_CHART);

Do we really want to oblige?

SQL has enough faults as a query language.  Adding general-purpose programming
features is unlikely to beautify it any.

jas