Beruflich Dokumente
Kultur Dokumente
THE S Q L D A T A B A S E L A N G U A G E
C.J.Date
P O Box 2647~ S a r a t o g a
California 9~.~7(.~ U S A
December 1983
sql critique
8
I. INTRODUCTION
powerful operators
improved d a t a independence
integrated catalog
T h e l a n g u a g e d o e s h a v e i t s w e a k p o i n t s too, however. In f a c t , it
c a n n o t b e d e n i e d t h a t S Q L in i t s p r e s e n t f o r m l e a v e s r a t h e r a lot
t o b e d e s i r e d -- e v e n t h a t , in s o m e i m p o r t a n t r e s p e c t s , it f a i l s
to realize the full potential of the relational model. The
purpose of t h i s p a p e r is t o d e s c r i b e a n d e x a m i n e s o m e of those
w e a k p o i n t s , in t h e h o p e t h a t s u c h a s p e c t s of t h e l a n g u a g e m a y b e
improved before their influence becomes too all-pervasive.
sql critique
9
sections:
formal definition
missing function
mi s t a k e s
Reference [3] g i v e s s o m e b a c k g r o u n d m a t e r i a l -- s p e c i f i c a l l y ~ a
set of principles that a p p l y to the design of programming
languages in g e n e r a l a n d d a t a b a s e l a n g u a g e s in particular. Many
of the criticisms that follow are expressed in t e r m s of those
principles. Note: Some of t h e p o i n t s a p p l y to i n t e r a c t i v e SQL
only and some to embedded SQL only~ b u t m o s t a p p l y to both. I
have not bothered to spell out the distinctions; the context
m a k e s it c l e a r in e v e r y c a s e . A l s o ~ t h e s t r u c t u r e of t h e p a p e r is
a little arbitrary~ in t h e s e n s e t h a t it is n o t really always
clear which heading a particular point belongs under. There is
also some repetition (I h o p e n o t t o o m u c h ) ~ for e s s e n t i a l l y the
same reason.
sql critique
I0
2. LACK OF ORTHOGONALITY: EXPRESSIONS
* A t~b_l_e_-eE.p.ces.si_on
- is a SQL expression that yields a table --
for example, the expression
SELECT *
FROM EMP
WHERE DEPT# = ~D3'
SELECT EMP#
FROM EMP
WHERE DEPT# = ~D3 ~
SELECT *
FROM EMP
WHERE EMP# = ~E2"
or the expression
SELECT SALARY
FROM EMP
WHERE EMP# = ~E2'
Note t h a t t h e s e f o u r k i n d s of e x p r e s s i o n c o r r e s p o n d t o t h e four
c l a s s e s of data o b j e c t ( t a b l e , c o l u m n ; r o w , s c a l a r ) s u p p o r t e d by
SQL -- though incidentally SQL i s i n c o n s i s t e n t as t o w h e t h e r i t s
e x p r e s s i o n s y i e l d v a l u e s or r e f e r e n c e s , i n g e n e r a l . Note t o o t h a t
(as pointed out in [3]) the four classes of object can be
partially ordered as follows:
sql critique II
table (highest)
V V
col umn row
V
s c a l ar (i o w e s t )
(columns are neither higher nor lower than rows with respect to
this ordering).
As e x p l a i n e d in [3] ( a g a i n ) , a l a n g u a g e s h o u l d p r o v i d e , for" e a c h
c l a s s of o b j e c t it s u p p o r t s , at l e a s t all of t h e f o l l o w i n g :
The table below shows that SQL does not really measure up to
these requirements.
sql critique 12
\ opn ~ constructor compare : assign : selector : gen
ob.j\ ~ ~ ~ expr
only via : : no
table : no no ~ INSERT - : yes : (see
SELECT : :below)
÷ ÷ + ~
: o n l y a s a r g to:
column : IN ( h o s t v b l e s : no : no : yes ~ no
: : & c:onsts only):
+ ,
SELECT scalar-expression-commalist
FROM t a b I e - n a m e - c o m m a l i st
WHERE predicate
sql critique 13
(i.e., SQL is r e l a t i o n a l l y complete). However, the table-
expressions of SQL (which are the SQL equivalent of the
expressions of t h e r e l a t i o n a l algebra) ~aQoQt be arbitrarily
nested. Let u s c o n s i d e r t h e q u e s t i o n of e x a c t l y w h i c h cases
SQL does support. Simplifying matters slightly, the expression
SELECT - FROM - WHERE is the SQL version of the nested
algebraic expression
sql critique 14
"Natural" formulation (projection of a union):
We r e m a r k in p a s s i n g t h a t a l l o w i n g b o t h f o r m u l a t i o n s of the
query would enable different users to perceive and express the
same problem in d i f f e r e n t ways (ideally~ of course~ both
formulations would translate to the same internal
representation~ for otherwise the choice between the two would
no longer be arbitrary).
The foregoing e x a m p l e t a c i t l y m a k e s u s e of t h e f a c t t h a t a
simple table-reference (i.e.~ a t a b l e - n a m e ) QYgh~ to be just a
s p e c i a l c a s e of a g e n e r a l t a b l e - e x p r e s s i o n . Thus we wrote
instead of
sql critique
IS
Elsewhere I have proposed some extensions to SQL to support
the outer join operation [4]. The details of t h a t p r o p o s a l do
not concern us here; what does concern u s is t h e f o l l o w i n g . If
the user needs to compute an o u t e r j o i n of three or more
relations, then (a) that outer _join is constructed by
performing a sequence of ~!i_[!~E2 o u t e r joins (e.g., join
relations A a n d B, then join the result and relation C); and
(b) it is e s s e n t i a l that the user indicate the sequence in
which tlnose binary joins are performed, because different
sequences wi i i produce different results, in general.
Indicating the required sequence is done, precisely, by
writing a suitable nested expression. Thus, nested expressions
are @=ss]eQt~i_al_ if S Q L is t o provide direct (i.e., single-
statement) support for general o u t e r j o i n s of m o r e t h a n two
tel a t i o n s .
sql critique
16
first preserves information for algebra courses only (as
required)., the second produces a l o t of u n n e c e s s a r y output.
And note that the first cannot even be formulated (as a s i n g l e
statement) if n e s t e d e x p r e s s i o n s are not supported.
Base table:
View d e f i n i t i o n :
Query (Q) :
SELECT *
FROM LONDONSUPPLIERS
WHERE STATUS > 50
SELECT S#., S N A M E ~ S T A T U S
FROM S
WHERE STATUS > 50
AND CITY = ~London ~
SELECT *
FROM ( SELECT S#., SNAME., S T A T U S
FROM S
WHERE CITY = ~London ~ )
WHERE STATUS > 50
sql critique 17
strangely enough it c a n b e u s e d t o d e f i n e t h e scope for a
cursor in e m b e d d e d SQL). So a view cannot be "any derivable
relation", and the relational closure property breaks down.
Likewise, I N S E R T ... S E L E C T c a n n o t b e u s e d t o a s s i g n t h e u n i o n
of two relations to another relation. Yet another consequence
of the special treatment g i v e n t o U N I O N i s t h a t it is not
possible to apply a builtin function such as AVG to a union.
See the following section.
SELECT :X + 1
FROM T
and so is:
UPDATE T
SET F = :X + 1
INSERT INTO T ( F )
VALUES ( :X + 1 )
sql critique 18
SELECT COLOR
FROM P
WHERE CITY =
( SELECT CITY
FROM P
WHERE P# = ~PI ~ )
UPDATE P
SET COLOR = ~Blue ~
WHERE CITY =
( SELECT CITY
FROM P
WHERE P # = ~Pi ~ )
UPDATE P
SET CITY =
( SELECT CITY
FROM S
WHERE S# = ~$1 ~
WHERE ...
Even w o r s e , given:
UPDATE EMP
SET SALARY = SALARY + ( SELECT BONUS
FROM BONUS
WHERE EMP# = EMP. EMP# )
sql critique 19
3. LACk-:] O F ORTIdOGONALITY: BUILTIN FUNCTIONE.;
(though once again the keyword SELECT seems rather obtrusive; QTY
FROM SF', or -- even better -- simply SP.QTY, would be more
orthodox). As another example, the query:
sql c r i t i q u e 20
SELECT S U M (QTY)
FROM SF'
WHERE P # = "F'~'
or (better) as:
SELECT P#
FROM SP
WHERE SUM (QTY) > 1000
~!~E~2 does not work, either with SQL~s rules-For argument scope
or with any other rules. The most logical formulation (but
retaining a SQL-like style) is:
SELECT P#
FROM SP
GROUP BY P#
HAVING S U M (QTY) > 1000
N o t e t h a t t h e u s e r is n o t r e a l l y interested in g r o u p i n g p e r s e in
this query; by writing G R O U P BY, h e or s h e is in e f f e c t telling
the system how to execute the query, w h i c h is c o u n t e r to the
general philosophy of t h e r e l a t i o n a l model. To put this another
way, the statement begins to look more like a prescription for
solving the problem, rather than a simple description of w h a t t h e
problem is.
sql critique 21
and the GROUP BY clause alsot come to ~b~ 2 ~ !~FZ2 EE ~E~
~[g~Q~ ~ 9 o ~ Q g C ~ ] ~ . ~ As a m a t t e r o f f a c t , it is possible to
p r o d u c e a SQL f o r m u l a t i o n o f t h i s e x a m p l e t h a t does n o t use GROUP
BY o r HAVING a t a l l , and i s f a i r l y close to " t h e most logical
formulation" suggested earlier:
SELECT DISTINCT P#
FROM SP SPX
WHERE 1OOO <
( S E L E C T S U M (QTY)
FROM SP SPY
WHERE SPY.P# = SPX.P# )
View definition:
CREATE V I E W P Q ( P#, T O T Q T Y )
AS S E L E C T P#, S U M (QTY)
FROM SP
GROUP BY P #
Attempted query:
SELECT *
FROM PQ
WHERE TOTQTY > 10OO
The following is a n o t h e r s t r i k i n g e x a m p l e of t h e u n o b v i o u s n e s s of
the scoping rules. Consider the following two queries:
sql critique 22
SELECT SUM (QTY) SELECT SUM (QTY)
FROM SP FROM SP
GROUP BY P#
In t h e f i r s t e a s e l t h e q u e r y r e t u r n s a s i n g l e v a l u e ; t h e a r g u m e n t
to the SUM invocation is t h e e n t i r e Q T Y c o l u m n . In t h e second
case,, the query returns multiple values; the SUM function is
invoked multiple times, o n c e f o r e a c h of t h e g r o u p s c r e a t e d by
the GROUP BY c l a u s e . N o t i c e h o w t h e m e a n i n g of the syntactic
construct "SUM(QTY)" is d e p e n d e n t on c o n t e x t . In fact,, SQL is
moving out of the strict tabular framework of the relational
model in t h i s s e c o n d e x a m p l e a n d i n t r o d u c i n g a n e w k i n d of data
object,, viz. a set Q~ tables ( w h i c h is of c o u r s e n o t t h e same
t h i n g a s a t a b l e at a l l ) . G R O U P BY c o n v e r t s a t a b l e i n t o a s e t of
tables. In t h e example,, S U M is t h e n a p p l i e d to (a c o l u m n w i t h i n )
each member of t h a t set. A more logical syntax might look
something like the following:
sql critique 23
AVG ( APPLY ( SUM, SELECT QTY
FROM ( GROUP SP BY P# ) ) )
Let us now leave the scoping rules and consider some additional
points. E a c h of S U M , AVG, MAX, and MIN can optionally have its
argument qualified by the operator DISTINCT. ( C O U N T @bjst h a v e i t s
argument so qualified., t h o u g h it w o u l d s e e m t h a t t h e r e is no
intrinsic justification for this requirement. For MAX and MIN
such qualification is legal but has no semantic effect.) If (and
o n l y if) D I S T I N C T is not specified., then the column argument can
be a "computed" column, i.e., the result of an arithmetic
expression - - for- e x a m p l e :
SELECT AVG ( X + Y )
FROM T
SELECT AVG ( X ) ~ 3
FROM T
Table functions
SELECT COUNT(S)
FROM SP
sql critique 24
COUNT ( SELECT
FROM SP )
or (better) as:
COUNT ( SP )
SELECT
FROM S
WHERE EXISTS
( SELECT
FROM SP
WHERE SP.S# = S.S# )
SELECT
FROM S
WHERE EXISTS ( SP WHERE SP.S# = S.S# )
or (better still):
SELECT DISTINCT S#
FROM SP
instead of:
DISTINCT ( SELECT S#
FROM SP )
sql critique 2S
or (better):
DISTINCT ( SP.S# )
N o t e : W e c o n s i d e r U N I O N ~ a l o n e of t h e o p e r a t o r s o~ t h e r e l a t i o n a l
algebra~ as a function in S Q L m e r e l y b e c a u s e of the special
syntactic treatment it is g i v e n . S Q L is r e a l l y a h y b r i d of the
relational algebra and the relational calculus; it is not
precisely t h e s a m e as e i t h e r , t h o u g h it l e a n s s o m e w h a t t o w a r d t h e
calculus -- a d i a l e c t of t h e c a l c u l u s t h a t d o e s n o t l e n d itself
v e r y n e a t l y t o s u p p o r t of U N I O N ~ h o w e v e r ~ w h i c h is p r e c i s e l y why
the special treatment is n e c e s s a r y .
sql critique 26
4. LACK OF ORTHOGONALITY: MISCELLANEOUS ITEMS
Let F be a database field that can accept null values, and let HF
be a corresponding host variable, with associated indicator
variable HN. T h e n :
SELECT F
INT0 :HF:HN
INSERT . . .
VALUES ( : H F : H N ... )
and
UPDATE ...
SET F = :HF:HN
WHERE F = :HF:HN
UF'DATE T
SET ...
WHERE CURRENT OF C
UPDATE CURRENT OF C
SET ...
sql critique 27
SELECT ...
FROM T
WHERE CURRENT OF C
SELECT
FROM EMP
WHERE DEPT# =
( SELECT DEPT#
FROM DEPT
WHERE CURRENT OF D
STEP C TO NEXT
SELECT ~ I N T O ... WHERE CURRENT OF C
(a) it is clearer;
sql critique 2B
FETCH CURRENT OF C I N T O . . .
SELECT
FROM EMP
WHERE DEPT# = (CURRENT OF C).DEPT#
UPDATE CURRENT OF C
SET ...
DELETE CURRENT OF C
Specifying O R D E R B Y in t h e d e c l a r a t i o n of c u r s o r C m e a n s t h a t t h e
statements UPDATE/DELETE ... CURRENT OF C are illegal (in f a c t ,
the declaration of C c a n n o t include a FOR UPDATE clause if ORDER
BY is specified). The rationale for this restriction is that
ORDER BY may cause the program to operate on a copy instead of o n
the actual data, and hence that updates and deletes would be
meaningless; but the restriction is unfortunate, to say the
least. Consider a program that needs to process employees in
department number o r d e r a n d n e e d s t o u p d a t e s o m e of t h e m a s it
goes. The user is forced to code along the following lines:
sql critique 29
We remark also that the FOR UPDATE clause is a little mysterious
(its real significance is not immediately apparent); it i s also
logically unnecessary. T h e w h o l e of t h i s a r e a s m a c k s of a most
unfortunate l o s s of p h y s i c a l data independence.
SELECT F, NULL
FROM T
EmQt~ sets
The statement
sql critique
3O
The statement
The statement
The statement
The statement
sql critique 31
also gives "not found" at the outer level.
UF'DATE T ...
I N S E R T I N T O T ...
( FETCH C ... )
- cannot be indexed
sql critique 32
- cannot be INSERTed from a constant or SELECT-expression
GROUP BY:
T h e f a c t is., a s i n d i c a t e d in t h e d i s c u s s i o n of f u n c t i o n s earlier.,
an orthogonal treatment of G R O U P BY would require a thorough
treatment of a n e n t i r e l y n e w k i n d o f d a t a object., n a m e l y the "set
of tables .... presumably a major undertaking.
sql critique 33
UPDATE statement to set F equal to G is:
f l + f2 + .. + fn
sql critique 34
SUM (Fi + F2)
H o_st_ v a r i a b l e s
Introduced names
The user can introduce names (aliases) for tables (e.g., FROM T
TX) b u t n o t f o r s c a l a r s (e.g., SELECT F FX). This latter facility
would be particularly useful when the scalar is in fact
represented as an operational expression -- e.g., S E L E C T A + B C.
The name C c o u l d b e u s e d in O R D E R B Y o r in G R O U P B Y or as an
inherited n a m e in C R E A T E V I E W (etc., etc.).
DELETE
FROM S
WHERE STATUS <
( SELECT AVG (STATUS)
FROM S )
UPDATE S
!SET STATUS = O
WHERE STATUS <
( SELECT AVG (STATUS)
FROM S )
INSERT INTO T
SELECT ~ FROM T
sql critique 35
~J. F O R M A L .DEFINITION
Questions:
sql critique 36
Does I_OCK SHARED acquire an S lock or an SIX lock [9]? If the
answer- is S, are updates permitted'7 When are locks acquired via
LOCK TABLE released?
!SELECT S#
FROM S
WHERE CITY = ~London'
ELECT P#
FROM P
WHERE CITY = ~London'
SELECT S#
FROM S
WHERE NOT EXISTS
( SELECT
FROM P
WHERE PCITY = SCITY )
SELECT S#
FROM S
WHERE NOT EXISTS
( SELECT
FROM P
WHERE PCITY = S.SCITY )
So also is:
SELECT S#
FROM S SX
WHERE NOT EXISTS
( SELECT
FROM P
WHERE PCITY = SX.SCITY )
scll c r i t i q u e 37
SELECT *
FROM S
WHERE EXISTS ( SELECT *
FROM SP SPX
WHERE SPX.S# = S.S#
AND SPX.P# = ~PI ~
AND EXISTS ( SELECT *
FROM SP SPX
WHERE SPX.S# = S.S#
AND SPX.P# = ~P2' )
SELECT *
FROM S
WHERE EXISTS ( SELECT *
FROM SP SPX
WHERE SPX.S# = S.S#
AND SPX.P# = ~PI' )
AND EXISTS ( SELECT *
FROM SP SPX
WHERE SPX.S# = S.S#
AND SPX.P# = ~P2 ~ )
(etc., etc.). In other words: What are the name scoping rules for
"aliases" (range variables)?
Butt how can this be done? The predicate "S.CITY = F'.CITY" does
not refer to any columns of T E M P i (it r e f e r s to columns of S and
P, o b v i o u s l y ) . Similarly, S.S# and P.P# are not columns of T E M P 2 .
In o r d e r for these references to be interpreted appropriately, it
is necessary to :ii n t r o d u c e cer tai n n am_e i_n_h_e~z~_ta n c e ~7.t=~l_~s,
indicating how resuit tables inherit column-names from their
source tables (which may of c o u r s e may themselves also be
[intermediate] result tables, witln i n h e r i t e d column-names of
scll c r i t i c l u e
38
their own). Such rules are currently defined only very
informally, if at all. Such r u l e s become even more i m p o r t a n t i f
SQL i s t o p r o v i d e s u p p o r t f o r n e s t e d e x p r e s s i o n s .
When exactly does a cursor iterate over the real "base data" and
when over a copy?
sql critique 39
6. MISMATCH WI]H HOST LANGUAGE
SQL objects (tables~ cursors~ etc.) are not known and cannot be
referenced in the host environment.
SQL object names and host object names are independent and may
clash. SQL names do not follow the scoping r u l e s of t h e h o s t .
SQL keywords and host keywords are independent and may clash
(e.g., P L / I S E L E C T vs. S Q L S E L E C T ) .
SQL and host may have different name qualification rules (e.g.,
T . F in S Q L vs. F O F T in C O B O L ; and note that the SQL form must
be used even for host object references in t h e S Q L e n v i r o n m e n t ) .
sql critique 40
SQL and host may have different data type conversion rules.
SQL and host may have different Boolean operators (AND, OR, and
N O T in S Q L vs. &, :, a n d ~ in P L / I ) .
SQL name resolution rules are different from those of the host.
sql critique 41
7. MISSING FUNCTION
(Note: It i s o b v i o u s l y p o s s i b l e t o e x t e n d t h e e x i s t i n g languaqe
to incorporate most i f n o t a l l o f t h e following features. We
mention them f o r c o m p l e t e n e s s . )
"Whole-record" UPDATE.
Cursor comparison.
Cursor assignment.
Cursor constants.
Cursor arrays.
Reusable cursors.
sql critique 42
8. MISTAKES
I h a v e a r g u e d a g a i n s t n u l l v a l u e s at l e n g t h e l s e w h e r e [6], and I
will not repeat those arguments here. In my o p i n i o n the null
v a l u e c o n c e p t is f a r m o r e t r o u b l e t h a n it is w o r t h . Certainly it
has never been p r o p e r l y t h o u g h t t h r o u g h in the existing SQL
implementations (see t h e d i s c u s s i o n u n d e r " L a c k of O r t h o g o n a l i t y :
Miscellaneous Items", earlier). For example, the fact that
functions s u c h as A V G s i m p l y i g n o r e n u l l v a l u e s in t h e i r a r g u m e n t
violates what should surely be a fundamental principle, viz: ! ~
~ ~ ~Qc3!.~ O ~ 2 ~ E p r o d u c e a ( s p u r i o u s l ~ 2 p r e c i s e a n s w e r to
gY~E2 w h e n t h e d a t a i n v o l v e d in t h a t g u e r 2 is i t s e l f ~mprecise.
At least the system should offer the user the explicit option
either to ignore nulls or to treat their presence as an
exception.
sql c r i t i q u e
43
Sometimes "table" means, specifically, a b_~se t a b l e (as in C R E A T E
TABLE); at other times it m e a n s "base table or view" (as in
COMMENT ON TABLE). Since the critical point about a view is that
it i s a t a b l e (just as the critical point about a subset is that
it i s a s e t ) , I w o u l d v o t e f o r t h e f o l l o w i n g changes:
(a) Replace the terms "base table" arid "view" by "real table"
and "virtual table" r espectivelv~
.q , .
"SELECT ~"
=ANY (etc.)
sql critique 44
problem, yet it i s n o t d i f f i c : u l t to find no less than seven at
least superficially distinct formulations for it ( s e e b e l o w ) . Of
course, the differences would not be important if al 1
formulations worked equally well, but that is unlikely.
1. SELECT SNAME
FROM S
WHERE S # IN
( SELECT S#
FROM SP
WHERE P# = ~F'2~)
2. SELECT SNAME
FROM S
WHERE S # ==ANY
( SELECT S#
FROM SP
WHERE P# = ~P2 ~ )
3. SELECT SNAME
FROM S
WHERE EXISTS
( SELECT
FROM SP
WHERE S# = S.S# AND P# = ~P2 ~ )
5. SELECT SNAME
FROM S
WHERE 0 <
( SELECT COUNT(U)
FROM SP
WHERE S# = S.S# AND P# = ~P2')
6. SELECT SNAME
FROM S
WHERE ~P2' IN
( SELECT P#
FROM SP
WHERE S# = S.S# )
7. SELECT SNAME
FROM S
WHERE ~P2 ~ =ANY
( SELECT P#
FROM SP
WHERE S# = S.S# )
sql critique
45
(where $ is any one of =~ >~ etc.) is equivalent to the WHERE
clause
A s a m a t t e r of f a t t y it i s n o t j u s t t h e c o m p a r i s o n operators =ANY
(etc.) that are redundant; the entire subquery construct could be
removed from SQL with effectively n o l o s s of function. (Nested
table- and column-expressions etc. would of c o u r s e still be
required~ as argued earlier.) This is ironic~ s i n c e it w a s the
subquery notion that was the justification for the "Structured"
in " S t r u c t u r e d Query Language" in t h e f i r s t p l a c e .
sql critique 46
9. ASPECTS OF THE RELATIONAL MODEL NOT SUPPORTED
3. An understanding of p r i m a r y k e y s is r e q u i r e d in o r d e r to
support the updating of v i e w s c o r r e c t l y . SQL~s rules for the
updating of views are in f a c t disgracefully ad hoc. We
consider projection: restriction, and join views in turn
b e l o w . Further- d i s c u s s i o n of t h i s t o p i c c a n be f o u n d in [7].
sql critique 47
underlying table for which duplicate elimination is not
requested (via D I S T I N C T ) -- w i t h a " u s e r b e w a r e " if that
subset does n o t in f a c t i n c l u d e t h e underlying primary
key. ( A c t u a l l y t h e s i t u a t i o n is e v e n w o r s e t h a n t h i s . E v e n
a c o l u m n s u b s e t is n o t u p d a t a b l e if t h e F R O M c l a u s e in t h e
d e f i n i t i o n of t h a t s u b s e t l i s t s m u l t i p l e t a b l e s . M o r e o v e r ~
updates are prohibited if duplicate elimination is
recluested ~ e v e n if t h a t r e q u e s t c a n h a v e n o e f f e c t b e c a u s e
the column subset does include the underlying primary
key.)
* E~E~gn ~
sql critique 48
SQL currently p r o v i d e s no s u p p o r t f o r d o m a i n s at all, except
i n a s m u c h as t h e f u n d a m e n t a l data types (INTEGER, FLOAT., e t c . ) c a n
b e r e g a r d e d as a v e r y p r i m i t i v e k i n d of d o m a i n .
A l i m i t e d f o r m of r e l a t i o n a s s i g n m e n t is s u p p o r t e d v i a I N S E R T ...
SELECT~ but that operation does not overwrite the previous
content of t h e t a r g e t t a b l e , a n d t h e s o u r c e of the assignment
c a n n o t b e an a r b i t r a r y algebraic expression (or S Q L e q u i v a l e n t ) .
, E~.p_.ii.~it ~.q.!.!~
sql c r i t i q u e 49
10. SUMMARY AND CONCLUSIONS
Of c o u r s e r I r e a l i z e t h a t m a n y of t h e s h o r t c o m i n g s i d e n t i f i e d in
t h i s paper- w i l l v e r y l i k e l y b e d i s m i s s e d as a c a d e m i c ~ t r i v i a l ~ or
unimportant by many people~ especially as SQL is so clearly
superior to o l d e r l a n g u a g e s s u c h a s t h e D M L of DBTG. However~
experience shows that "academic" considerations have a nasty
h a b i t of b e c o m i n g h o r r i b l y p r a c t i c a l a f e w y e a r s f u r t h e r d o w n t h e
road. T h e m i s t a k e s w e m a k e n o w w i l l c o m e b a c k t o h a u n t u s in t h e
future. Indeed~ the language in i t s p r e s e n t f o r m is already
proving d i f f i c u l t t o e x t e n d in s o m e ( d e s i r a b l e ) w a y s b e c a u s e of
limitations in i t s c u r r e n t s t r u c t u r e . A v e r y t r i v i a l e x a m p l e is
provided b y t h e p r o b l e m s of a d d i n g s u p p o r t f o r c o m p o s i t e fields
(i.e.~ m i n o r s t r u c t u r e s ) .
sql critique SO
ACKNOWLEDGMENTS
sql critique 5!
REFERENCES
sql critique B2
APPENDIX: SQL STRONGPOINTS
_FjQM~E-F.LjI. Q~e_rat~r.~
It is v e r y e a s y to l e a r n e n o u g h of t h e S Q L l a n g u a g e t o "get on
the air" and start doing real, useful work; thus, the initial
l e a r n i n g p e r i o d is t y p i c a l l y v e r y s h o r t i n d e e d -- c e r t a i n l y hours
r a t h e r t h a n d a y s or w e e k s .
sql critique 53
SQL can be used both interactively (i.e., as a q u e r y language)
and embedded in a program (i.e., as a database programming
language). This property is d e s i r a b l e for several reasons. First,
it i m p r o v e s c o m m u n i c a t i o n : End-users and application programmers
are "speaking the same language" Second, it m a k e s p r o g r a m m e r s ,
as well as e n d - u s e r s , more productive -- t h e b e n e f i t s sketched
above (e.g., the provision of h i g h - l e v e l operators) apply to
programmers too. And third, the interactive interface provides a
very convenient programmer debugging facility; that is~
application programmers can take the SQL portions of their
program and debug them interactively at t h e t e r m i n a l .
~!~QQ ~ o~timization
S Q L is c a p a b l e of e f f i c i e n t implementation, v i a t h e by n o w w e l l -
known compilation/optimization techniques pioneered in the IBM
prototype S y s t e m R. Moreover, t h e f a c t t h a t S Q L is c o m p i l e d , and
hence t h a t s y s t e m s s u c h as S y s t e m R a r e " e a r l y b i n d i n g " systems,
does not compromise the flexibility of t h o s e s y s t e m s . If a c h a n g e
is made to the database (such as t h e d r o p p i n g of an i n d e x ) that
invalidates an e x i s t i n g c o m p i l e d p r o g r a m , then that program --
or, more accurately, the SQL statements within that program --
will automatically be r e c o m p i led and rebound on the next
invocation. Thus the system can provide the flexibility of late
binding without incurring the interpretation overheads normally
associated with such systems.
sql critique 54