djo7613@blake.acs.washington.edu (Dick O'Connor) (03/29/90)
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@dtic.dla.mil uunet!dgis!jkrueger ************************************************************************* In article <6393@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@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@math.ams.com / | / |/ | / ._ / a programmer, NYNEXNET: (401) 272-9500 x4020 / = | / ._. | \_. \ but I play one FAX: (401) 331-3842 /__/|__| /__/ |__| /____/ at the AMS... -------