Path: utzoo!mnetor!uunet!husc6!hscfvax!pavlov
From: pavlov@hscfvax.harvard.edu (G.Pavlov)
Newsgroups: comp.databases
Subject: Re: Quel vs SQL in Ingres 5.0
Message-ID: <551@hscfvax.harvard.edu>
Date: 11 Apr 88 01:42:55 GMT
References: <4350@ihlpf.ATT.COM>
Organization: Health Sciences Computing Facility, Harvard University
Lines: 77
Keywords: quel, sql, ingres

In article <4350@ihlpf.ATT.COM>, mohan@ihlpf.ATT.COM (Mohan Palat) writes:
> 		SQL vs QUEL in Ingres 5.0
> 		-------------------------
> 	In Ingres 5.0, all SQL queries are converted to QUEL and then
> 	handled in the usual manner. Hence, there is no performance
> 	advantage in using SQL over QUEL, in an Ingres 5.0 application.
> 	Is this true?
> 	Apart from performance, is there any significant (dis)advantage
> 	in using QUEL/SQL in Ingres 5.0?

  I don't know if anyone chooses SQL over anything else because of performance,
  tho there are several DBMS vendors out there who will try to convince you
  that there is a relationship between the two.

  I can offer three "answers" to your two questions:

   1. RTI will be releasing version 6 in the upcoming months (staggered release;
      VMS first).  In version 6, SQL will run in native mode.

   2. The main reason SQL is this year's "hot" solution is that it is expected 
      to become the "standard" for relational dbms query and the majority of 
      major dbms vendors that I know of either have added SQL or are in the 
      process of doing so.  In many cases (RTI, for example), this has been for
      marketing reasons, pure and simple. 

      Using SQL is supposed to guarantee a site long-term portability - e.g., 
      move your db to another machine & dbms with less pain if your present one
      goes under, fails to port to your preferred hardware platform, etc.  Or,
      you wish to distribute your workload between mini/mainframes and pc's,
      and you are forced into running different dbms's on each category of 
      machine. 

      My own view on the SQL portability issue is:

      a. the portability issue is overexaggerated.  SQL is not a language per
         se and covers only a subset of the total set of operations that a dba
         or systems administrator must perform.  Also, there is no consistency
         in call syntax from HLI's.  Some use preprocessors to convert embedded
         statements, others simply provide a set of subroutines; some require
         alignment on word boundaries, others don't, etc.
 
      b. having had some experience in porting between totally dissimilar rela-
         tional or pseudo-relational dbms's, I would say that moving from one
         command set to another is not likely to be that much more painful 
         than moving from one SQL-based system to another.  In part this is 
         because one typically is performing a very limited set of dbms mani-
         pulations in an HLI-based program and the number of lines of code that
         must be changed (or, even, changed substantially) is not that large.
         And operations such as screen manipulation must be largely done out-
         side of command sets such as SQL anyway.

      c. I expect that the majority of the major dbms vendors will ultimately
         provide "gateways" between their systems and other "best sellers" -
         which will be reasonably transparent, such as RTI's current QUEL->
         SQL conversion.

  3. We use QUEL almost exclusively; we believe it to be more powerful.  How,
     you might ask ?  To be honest, I can't say much, since it has been a long
     time since I have had the privilege of having to use SQL.  But one example
     comes to mind:  during our dbms evalutaion, the following proved to be 
     easy to do in QUEL and a pain in SQL.  I only list the QUEL version, since
     I do not remember what was required from SQL and I do not want to prejud-
     ice it with an overly complex solution.  Maybe someone else can help out.

     Application:  update attribute a1 in table a with attribute b1 in table b,
     wherever the value of a2 in table a is the same as the value of b2 in 
     table b.

     QUEL:

      replace a (a1=b.b1) where a2.a = b2.b


   - In spite of what I said in the above, SQL is probably the safer choice,
     career-wise if nothing else.

     greg pavlov, fstrf, amherst, ny