Resolution of SQL debate

sowa@watson.ibm.com
Message-id: <199201040004.AA19088@venera.isi.edu>
Date: Fri, 3 Jan 92 19:03:19 EST
From: sowa@watson.ibm.com
To: srkb@isi.edu, interlingua@isi.edu, kr-advisory@isi.edu, cg@cs.umn.edu
Cc: jonesm@atc.boeing.com, speyer@mcc.com, tyler@cme.nist.gov,
        mzemanko@note2.nsf.gov, jwinkler@nasamail.nasa.gov
Subject: Resolution of SQL debate

Yesterday, I spoke on the phone with Jim Fulton and with one of the
people on the ANSI committee that is defining SQL2.  We reached an
amicable resolution of the issues concerning SQL that Jim and I had
been debating in recent notes.

The ANSI representative confirmed most of the points about SQL2
that were made by the ISO representative, whose comments I quoted
in a previous note, but he interpreted them in a slightly more
favorable light.  I will leave both of them unnamed, since they are
actively involved in negotiations, and I don't want to commit them
to positions that they might prefer not to state in public.

The ANSI representative said that the full SQL2 is indeed in an
unsettled state.  It now consists of 500 pages, which is over an
inch thick, double spaced.  The change proposals to be considered
in the editing session later this month are nearly two inches thick.
However, there are three different levels of description:

 1. The entry level is essentially a cleaned-up version of the 1989
    standard with some of the optional features made mandatory.  A
    vendor who has an implementation of the 1989 standard should be
    able to bring it up to the entry level of SQL2 in about 3 years.

 2. The intermediate level adds about another 150 pages of definition
    to the entry level.  Implementing it completely would probably take
    at least 5 years, but even that is an optimistic estimate.

 3. The full level adds another 200 pages of definition, which is
    still in a highly unsettled, undebugged state.  The person I spoke
    with estimated that any vendor would take at least 10 or 20 years
    to implement it.

This implies that for practical purposes, the knowledge sharing people
need not worry about full SQL2 for a long time.  Even the intermediate
level isn't likely to be in use until at least 1997.  The entry level
must be considered, but it isn't substantially different from the
current version of SQL, which is important because there are over 100
commercial implementations.  (AI researchers may not believe it, but
there are a lot more people in the world who know SQL than know LISP.)

In the conversation with Jim Fulton, we agreed that a logic-based
conceptual schema should be upward compatible with existing approaches.
Anyone who is happy with E-R diagrams, SQL, COBOL, and current CASE
tools should be able to continue using them indefinitely.  Older
applications should be able to run unchanged, and they should be
able to coexist with new applications that use the new facilities
and tools that are being developed.

The question of notation is potentially a big stumbling block, since
people do not want to change their familiar languages.  COBOL programmers
would no sooner switch to LISP notation than LISP programmers would
switch to COBOL.  Those of us who have been using other notations for
logic find SQL notation very distasteful, but some people seem to feel
comfortable with it.

Fulton wants to placate the SQL fans by assuring them that an SQL-like
notation for the conceptual schema would be possible.  Its semantics
would be identical to the logic-based approach that we are advocating,
but it would use the SQL syntax and keywords like SELECT.  I don't
believe that an SQL version of the logic-based semantics could be
defined as an *extension* of the current SQL or the proposed SQL2.
Instead, it would be necessary to start with a severely stripped-down
version of SQL with all the implementation dependencies removed.  Then
the new features would be added one at a time to express the common
semantics, using existing SQL keywords whenever possible.

I don't think that anyone starting from scratch would eagerly embrace
the SQL notation, but it might be useful as a bridge for programmers
who had been using SQL for database access.

John Sowa