SQL and QUEL under Ingres/Ultrix

[Dick O'Connor]

I received several responses to my question about the differences between
SQL and QUEL under Ingres.  The bottom line suggests that new applications
should use SQL (more of a standard) rather than QUEL (a proprietary
version) for compatibility.  Here's a summary of representative responses:
************************************************************************
In comp.unix.questions you write:

>We're just getting started on a campus machine running a test version of
>Ultrix (4.0) and I need to get some familiarity with Ingres on this OS.  
>I have lists of documents published for UNIX systems by the Ingres Corp.,
>but I can't figure out the difference between SQL and QUEL.

They are entirely different query languages.  For example, 
for an employee database like

	+----------+
	| employee | empid   name           dept
	+----------+-------+--------------+-------+
		   |    1  |  Joe Smith   |    1  |
		   |    2  |  Fred Farkle |    1  |
		   |    4  |  Amy Carter  |    2  |
		   +-------+--------------+-------+

	+------------+
	| department | deptid  name
	+------------+-------+-------------------+
		     |    1  |  shoe   	         |
		     |    2  |  rubber novelties |
		     +-------+--------------+----+

"who works in the shoe department" is QUEL:

	range of e is employee, d is deparment
	retrieve (e.name) where d.name = "shoe"
	and e.dept = d.deptid

and SQL:

	select name from employee e, department d where
	d.name = "shoe" and e.dept = d.deptid

As may be seen, they are similar but hardly compatible.  QUEL
is easier to learn and technically superior but not profoundly
so.  SQL is the market standard.  If you want to retain portable
applications, SQL is part of what you have to do.  (Other parts
are not using vendors' extensions to SQL, writing portable host
code, portable build and run procedures, using portable user
interface tools like curses or X Windows, etc. etc. etc., so
don't think that using SQL will magically make your applications
portable).  If you want to get up and running as fast and
painlessly as possible, QUEL is better.  You can choose later
to convert it to SQL.  I find I write more than 10 lines of
other code for each line of query language code, so it's not
a major conversion project in that context.

-- Jon
--
Jonathan Krueger    jkrueger at dtic.dla.mil   uunet!dgis!jkrueger
*************************************************************************

In article <6393 at blake.acs.washington.edu> you write:
>We're just getting started on a campus machine running a test version of
>Ultrix (4.0) and I need to get some familiarity with Ingres on this OS.  
>I have lists of documents published for UNIX systems by the Ingres Corp.,
>but I can't figure out the difference between SQL and QUEL.
>
<<stuff deleted>>

SQL and QUEL are completely different query languages.  Quel is 
of use only to people with existing quel applications.  You are
encouraged/advised/warned that SQL is the database language of the 90s,
and you should do all your work in it rather than quel.

-dB

David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb at rtech.com
***********************************************************************

We use Ingres here on VMS with both QUEL & SQL. QUEL was Ingres' own home-brew
query language. It's quite powerful, and may still have some features that SQL
doesn't have. SQL is the query language developed by IBM for their DB2 product.
IBM being who they are, SQL has evolved into the defacto standard for query
languages. Ingres V5.something implemented SQL as a pre-processor to QUEL. It
was not elegant. However, QUEL features started to migrate over to SQL. Since
Ingres V6.0 their SQL implementation (now it's own query engine) is much
better. We have been advised by Ingres to do future development in SQL. We have
older QUEL-based applications that will likely be converted at some point in
the future. At this point, almost anything you want to do with QUEL can be done
with SQL. In the future, I imagine QUEL will fall behind SQL in power. Either
product embedded in a higher language program will have lots more flexibility
than in stand-alone .osl or .osq modules. I would recommend getting all the SQL
manuals (stand-alone and embedded) and not deal with QUEL, since you don't have
old QUEL applications to maintain. If you want more technical discussions,
there are Ingres geeks here who can be as detailed as you want. I'm just a
lowly applications programmer (in COBOL, even ;-) who has picked these insights
up from Ingres training classes and manuals. Good luck!

Tom Maloney - American Math Society  ____.    __. __.   ____.   Hi - I'm not
INTERNET: tjm at math.ams.com          /    |   /  |/  |  / ._ /   a programmer,
NYNEXNET: (401) 272-9500 x4020     /  =  |  /  ._.  |  \_. \    but I play one
     FAX: (401) 331-3842          /__/|__| /__/  |__| /____/    at the AMS...
-------