johan@mcvax.UUCP (03/25/87)
Last year we bought Ingres from RTI for a VAX 750, running
UNIX 4.3 BSD; we got V 3.0, with QUEL; some applications are
running or under construction.
In february we got V 5.0 with an additional SQL- based
interface (with RTI- extensions).
Now we are considering transition from QUEL to SQL.
Some of our considerations are:
1. The `holy' :-) Date wrote, that QUEL was `better' than SQL.
Comparison of the manuals didn't show any difference
in functionality (of course with the exception of the macro
facility in the interface to the language).
SQL may be a bit wordier than QUEL.
Probably Date's statement is based on some older implementation
of SQL.
2. In V 5 SQL is implemented as a front end to QUEL.
3. RTI states to bring in V 6 a direct SQL- interface, which
will be a superset of ANSI- SQL.
4. RTI states not to stop QUEL- support, but will they continue
providing extensions?
5. The advantage of using a standard DB- language seems clear,
but is it real? One might argue, that most of the work for larger
applications will consist of the specification of forms- interfaces
and data-manipulation, e.g. in OSL and/or EQUEL; even if one uses
SQL the compatibility with other SQL- systems might be small.
We are interested to know, what other users will do.
Please mail me your views, plans and additional information
on the subject of the transition from QUEL to SQL;
we are specially interested to learn, what the sites with a
longer Ingres- tradition will do: change all their applications
to SQL, continue their existing applications in QUEL but use SQL
for new ones, or continue the QUEL- use for their new applications
as well.
If I get enough response, I'll summarize to the net.
--
Johan Wolleswinkel
CWI, Postbus 4079, 1009 AB Amsterdam, Kruislaan 413, The Netherlands
Phone: +31 20 5924050 Telex: 12571 (mactr nl)
UUCP: johan@turing.cwi.nl or ...{seismo,philabs,decvax}!mcvax!johanbillc@blia.UUCP (03/26/87)
In article <327@turing.mcvax.cwi.nl>, johan@mcvax.cwi.nl (Johan Wolleswinkel) writes: > > 1. The `holy' :-) Date wrote, that QUEL was `better' than SQL. > Comparison of the manuals didn't show any difference > in functionality (of course with the exception of the macro > facility in the interface to the language). > SQL may be a bit wordier than QUEL. > Probably Date's statement is based on some older implementation > of SQL. QUEL really IS better than SQL. There is a large class of queries that are easy to do in QUEL but quite difficult in SQL. Furthermore, there are many queries, easy in QUEL, that are utterly impossible to do in SQL unless you do several queries using explicit temporary relations. QUEL has much more functionality. QUEL is made up of simple rules from which complex queries may be built. SQL is full of special cases, non-orthogonal constructs, and strange restrictions. Date recently said (unofficially, to a friend) that he could write an SQL grammar in 5 1/2 printed pages, and a QUEL grammar in 2 pages, and QUEL clearly had more functionality. And believe me, some of the gotchas in SQL are very irritating! Comparing SQL to QUEL is like comparing C to COBOL -- you can do the same things, but one is a lot more `powerful' than the other. My qualifications: I wrote a what can be loosely characterized as an SQL-to-QUEL translation package (somewhat similar, I suspect, to what RTI did). By the way, the reverse translation (QUEL-to-SQL) is not even remotely possible. By the way, I STRONGLY recommend Date's articles in the SIGMOD Record, Nov. 84 (vol. 14, no. 3). These have been reprinted in some anthology, too. There are two articles: one discusses criteria for evaluating query languages, and the second shows how SQL fails those criteria, with suggestions for improvements. The articles are both highly entertaining. -- W.H.Coffin. If you must, try ucbvax!{mtxinu|ucsfcgl}!blia!billc >> the usual disclaimer about my employer and my wretched opinions. << >> the usual witticism that swells netnews to ridiculous proportions. <<
allbery@ncoast.UUCP (04/01/87)
As quoted from <1902@blia.BLI.COM> by billc@blia.BLI.COM (Bill Coffin): +--------------- | In article <327@turing.mcvax.cwi.nl>, johan@mcvax.cwi.nl (Johan Wolleswinkel) writes: | > 1. The `holy' :-) Date wrote, that QUEL was `better' than SQL. | | QUEL really IS better than SQL. There is a large class of queries that | are easy to do in QUEL but quite difficult in SQL. Furthermore, | there are many queries, easy in QUEL, that are utterly impossible to do in | SQL unless you do several queries using explicit temporary relations. | QUEL has much more functionality. | | QUEL is made up of simple rules from which complex queries may be built. | SQL is full of special cases, non-orthogonal constructs, and strange | restrictions. Date recently said (unofficially, to a friend) that he +--------------- Can someone please mail me a description of QUEL, or a book about it from which I may glean the means to implement a QUEL-type language on top of another database manager? (Prime contender is UNIFY; not only is their SQL incompatible with ANSI SQL, it's even more restrictive; and, having worked with UNIFY SQL and INFORMIX-SQL, I'm heartily sick of both!) I am also interested in evaluating whether complex data manipulation and modification can be done with it reasonably easily and with little overhead enforced by the language (INFORMIX-SQL will never do MRP). A Yacc skeleton would be useful, but not required, as I can generate one from a sufficiently detailed description. A book on QUEL the language (as distinct from QUEL the Ingres programming environment/etc.) would be useful only if a pointer to the publisher is provided; no computer book stores around here want anything to do with non- IBMPC books or UNIX fundamentals. Thanks in advance, ++Brando (P.S. To the person who answered my last request for this with the comment that QUEL is algebraic and SQL is calculus; maybe, but this isn't math. SQL is altogether too limited in its capabilities, due to its non-procedural structure which requires complex manipulations to be done with a single SQL statement or else eat large amounts of disk spacve and processing time. As for Progress, show me a version that doesn't thrash memory; I start up the demo on our 7-meg Plexus and everything else swaps out!) -- ____ ______________ / \ / __ __ __ \ Brandon S. Allbery | /^\ USS ___ | /__> / \ / \ aXcess Company | A A A CHALLENGER / \ | | `--, `--, 6615 Center St. #A1-105 | H V H | | \__/ \__/ \__/ Mentor, OH 44060-4101 | H . H SEVEN \____/ \______________/ +1 216 974 9210 | / | \ WHO ________________________________________________________| /___|___\ DARED As long as there is the spirit to dare new frontiers, the dream will never die. cbatt!cwruecmp!ncoast!allbery ncoast!allbery%case.CSNET@relay.CS.NET BALLBERY (UUCP) (CSNET/Internet) (MCIMail)
billc@blia.UUCP (04/02/87)
In article <2263@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: > Can someone please mail me a description of QUEL, or a book about it from > which I may glean the means to implement a QUEL-type language on top of > another database manager? (Prime contender is UNIFY; not only is their The only stuff I know of that covers QUEL was originally published as technical reports by the INGRES project at UCB. Much of this material has been republished in "The INGRES Papers: Anatomy of a Relational Database System" Michael Stonebraker, editor. Published by Addison-Wesley (Reading, MA 01867), 1986. This book is probably fairly technical, and doesn't include the QUEL reference manual or tutorial. The BSD 4.3 documentation has the reference manual. About "calculus" vs. "algebra": someone's been reading promotional hype. Good relational query languages should be non-procedural. That is, the user should ask for the desired data without specifying how that data should be fetched. QUEL is fairly non-procedural. The semantics of SQL subqueries, as described in the ANSI standard, are VERY procedural. This makes it inherently dificult to optimize SQL, and subverts the relational goal of hiding data organization from the user. Again, a user should be able to ask for data without any procedural baggage -- let the DBMS figure out the query strategy. -- W.H.Coffin. billc@blia.BLI.COM Or, if you really like source routing, try ucbvax!{mtxinu|ucsfcgl}!blia!billc >> the usual disclaimer about my employer and my wretched opinions. << >> the usual witticisms that swell netnews to ridiculous proportions. <<