Quel Interview Questions and Answers - DoAnswers.com

QUEL is a relational database access language, similar in most ways to SQL, but somewhat better arranged and easier to use. It was created as a part of the groundbreaking Ingres effort at University of California, Berkeley, based on Codd's earlier suggested but not implemented Data Sub-Language ALPHA. QUEL was used for a short time in most products based on the freely-available Ingres source code, most notably Informix. As Oracle and DB2 started taking over the market in the early 1980s, most companies then supporting QUEL moved to SQL instead. In many ways QUEL is similar to SQL. One difference is that QUEL statements are always defined by tuple variables, which can be used to limit queries or return result sets.

QUEL Interviews are getting tough these days as the technology grows faster. To get through the QUEL interview one needs to update him/herself in a regular manner. Having said that, just before the interview, it is very important to have a quick glance of the reputed QUEL questions and answers to make yourself comfortable during the interview process. This is where DoAnswers.com helps you in renewing yourself on QUEL and various other technologies interview preparation.

VERY different, although in embedded applications, where the two DMLs are used only for the basic operations of fetching, updating and inserting, the differences are not very apparent. A few of the important differences in embedded applications are: (1) In EQUEL the INGRES identifiers are flagged (viz #part_no = part_no), while ESQL the host-language identifiers are flagged (viz part_no = :part_no). (3) QUEL allows range variables (analogous to SQL correlated table names) to remain defined between statements. A range variable declaration need not appear in the source code anywhere near the reference to the range variable. (4) The EQUEL `APPEND' statement (analogous to SQL `INSERT') insists that column be identified by name--columns cannot be addressed by position. (5) EQUEL allows the WHERE clause to be defined dynamically, without recourse to a "dynamic" EQUEL. As well, some of the other difference that apply to both the embedded and non-embedded version of QUEL, but which are perhaps of great importance when converting an application to SQL are: (1) Some of the more exotic QUEL access controls are not imposed on SQL accessors--this creates a potential security breach. (2) Outwardly identical SQL and QUEL views can produce different results because of semantic differences. (QUEL implements views so that they act like modifications to the WHERE clause, SQL implements them so that they act like virtual tables--with duplicates permitted.) (3) QUEL auto-commits by default; multi-statement transactions must be explicitly encapsulated between a BEGIN TRANSACTION and an END TRANSACTION or an ABORT. In non-embedded uses, such as `iquel' and Report Writer, the differences can be very great. A future version of this FAQ may deal with this more thoroughly.

The answer to this question will depend on circumstances. The best answer that can be offered is a list of the pros and cons of conversion. The implicit reason for wanting to do this will usually be a desire to be able to hire SQL programmers off the street, or to take advantage of recent Ingres enhancements that are available only in SQL. The advantage of being able to hire SQL programmers off the street is probably deceptive. SQL as such constitutes less than 3% of the source code (by one estimate), so familiarity with Ingres' forms run-time system and Ingres utilities will always be the main obstacle to recruiting experienced programmers. Wanting to take advantage of new Ingres facilities is a compelling reason to convert to SQL. In embedded applications, the conversion of QUEL to SQL is fairly mechanical, and can probably be undertaken at minimal cost. If necessary it is possible to do the conversion piecemeal, mixing SQL and QUEL in the same application. See Advisor note US_13270 for details. In the case of Report Writer, the conversion will in general be much more difficult. It is possible to do some very sophisticated data reduction in QUEL, and if a report makes use of some of the more powerful capabilities of QUEL, conversion to SQL may well be so painful that it should be avoided if at all possible. If it cannot be avoided, plan to spend a long time on the conversion and on testing. It is not unknown for a relatively modest report of under a 100 lines of code using QUEL to balloon to over 2000 lines of code when switching to SQL. <> 10.005 Are there any utilities for converting QUEL to SQL? Q2 is a commercial QUEL to SQL converter which automatically converts a high percentage of QUEL to SQL, and identifies and isolates the remainder. It is available through Common Sense Computing, who offer a trial service which allows you to e-mail or send sample QUEL programs for conversion so you can judge for yourself the effectiveness of the conversion. Contact details for Common Sense Computing are given in section 01.017 of this document.

QUEL is the original INGRES DML, now supplanted by SQL for commercial reasons. There is a small number of very well regarded authorities, as well as long-time Ingres users who believe that QUEL is superior to SQL. QUEL is available as part of the INGRES base system. The interfaces are `quel' (a terminal monitor equivalent and similar to `sql') and `iquel' (similar to `isql'). Report Writer is able to determine automatically whether SQL or QUEL is used in the .QUERY section. The embedded pre-processor is `eqc' for C. QUEL is based on the relational calculus; SQL is based on the relational algebra. There are many operations that are straight forward in QUEL that are not readily reproduced in SQL. Although it is de-emphasized, QUEL _IS_ supported and Computer Associates has not yet announced that it will be dropped.