Path: utzoo!mnetor!uunet!lll-winken!lll-tis!daitc!jkrueger
From: jkrueger@daitc.ARPA (Jonathan Krueger)
Newsgroups: comp.databases
Subject: Re: Quel vs SQL in Ingres 5.0
Message-ID: <47@daitc.ARPA>
Date: 17 Apr 88 20:33:48 GMT
References: <4350@ihlpf.ATT.COM> <3560011@wdl1.UUCP>
Reply-To: jkrueger@daitc.UUCP (Jonathan Krueger)
Organization: Defense Applied Information Technology Center, Alexandria VA
Lines: 35

In article <3560011@wdl1.UUCP> mitchell@wdl1.UUCP (Jo Mitchell) writes:
>I've seen countless disjoint queries [in QUEL]...MAJOR OOPS.
>This never happened in SQL. 

I agree, this is a flaw in QUEL.

>	Something else I miss is the "not in" ...
>	   select count(*) from realtable where value not in legaltable.values)

The QUEL syntax is:
	range of r is realtable
	range of l is legaltable
	retrieve (missing = count(r.all
		where any (r.value by l.values where r.value = l.values) = 0))
which I admit is a less intuitive way of expressing a difference operation
than the SQL syntax.

However, QUEL's "any" yields a value that can be used in expressions in an
ordinary way.  For instance,
	retrieve (at_least_one = any(r.all where r.name = "Sam"))
This turns out to be useful in short-circuiting queries.  For instance,
if the column isn't indexed, or if the query defeats indexing:
	retrieve (at_least_one = any(r.all where r.name = "*Sam*"))
the query can return TRUE as soon as it hits the first match, rather
than exhaustively passing through the table.  As implemented in RTI INGRES
5.0, that's exactly what it does.

However, the number of cases where this matters has got to be small.
So I'd say you have two valid criticisms of QUEL.  Since the relational
model doesn't specify the query language syntax for its implementation,
I see little reason not to prefer the better syntax.  It's beyond
argument that better ones than QUEL or SQL exist.  We'll see them in
five or ten or twenty years, depending on how much we cling to existing
ones.

-- Jon