Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.databases
Subject: Re: Network vs. Relational DBMSs
Message-ID: <503@cresswell.quintus.UUCP>
Date: 2 Jan 88 03:01:34 GMT
References: <2550@sfsup.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 121
Summary: SQL =/= Relational Databases

In article <2550@sfsup.UUCP>, prj@sfsup.UUCP (Paul Jayne) flames against
relational databases.  He says a number of things:

> 	Complex problems don't become simple because we want easy answers.
Absolutely right.

> 	The big lie of Relational Technology is that all human applications
> 	can be reduced to a set of tables and a set of clever queries.
There's a half truth in here.  Anything which a network data base can do
a relational data base should be able to do.  I commend to you the book
	Relational Database, selected writings
	C. J. Date
	Addison-Wesley, 1986
	ISBN 0-201-14196-5
Actually, everything of Date's that I've seen is good value.

I'm not quite sure what Jayne means by "human applications", but I'll agree
that most human affairs are not adequately treated by any sort of data
base.  (There was a rather good critique of the "British Nationality Act"
program in the Computer Journal a couple of years ago; I'm sorry I can't
supply the reference.)  But I repeat, this applies to a network data base
just as well.  (The difference between a network data base and a relational
data base is that in a network data base some of the joins have already
been done for you, and most of the rest are nearly impossible to do.)

> 	Data complexity doesn't disappear when you hide it in the form of
> 	torturous SQL statements.
[Spelling: did he mean 'tortuous' = "involved, not straightforward"?]

Please don't confuse SQL with relational data bases.  SQL is to
relational data bases as IBM PCs are to computers:  in both cases you
have something which *looks* simple and has encouraged more people to
use this kind of tool and which has even facilitated portability of
applications, but which is a design *disaster*. I am a dyed-in-the-wool
logic/relational data base/Prolog enthusiast, and I find SQL unbelievably
clumsy for even the simplest query.  As for anything complicated, ack
thpt.  As Date points out, SQL doesn't even support primary keys, which
are to relational data bases what links are to network data bases.

> Relational DBMSs succeed when they fill the niche of fairly easy systems that
> aren't worth the expense of doing a full-blown application.  They fail rather
> dismally when they meet up with anything complex.  If they were all they claim
> to be, many or most network systems would have been converted by now.  In fact,
> no large complex system has ever been converted (corrections, please) to a
> Relational DBMS -- the usual approach is to do "new" development on the new
> system (which means the easy stuff they didn't have time for).

Look at that third sentence:
>	If relational data base systems were all they claim to be,
>	many or most network systems would have been converted by now.
This is just plain false.  It is extremely rare for ANY complex
application of ANY sort to be "converted".  Conversion is not free:
the cost of doing a conversion can easily exceed the benefits of
having the result.  Then there is another point.  Suppose we have a
problem P and two methods M1 and M2.  Solving P using M1 leads to a
solution S1.  Solving P using M2 leads to a solution S2.  Suppose
that there is reason to believe that S2 would be clearly superior
to S1, but that we already have S1.  It may be *impossible* to convert
S1 to S2.  (S1 may have ignored characteristics of P that S2 needs.)
It may even be the case that there is no-one around any more who
recalls clearly what P was, or how S1 was derived from it.  So it
may not be possible/worthwhile producing S2 *now*, even though it
would have been better if M2 had been available originally.
Chapter 12 of Date's book explains why it would be difficult to convert
IMS applications to SQL (basically, while SQL is retarded, IMS is
totally insane).

Paul Jayne is actually praising relational data bases here.
The first and last sentences of that paragraph above are an admission
that the cost of developing an application in a non-relational system
may be too high to do even "easy stuff".  What a condemnation!
 
It simply isn't true that relational systems "fail rather dismally"
when they meet anything complex.  It is precisely when you have
complicated *problems* that you need *tools* of the utmost
simplicity and reliability.  Whatever the reliability of SQL, it is
not simple.  I can readily believe that SQL is hard to use for hard
problems.  But that it is not because it presents the relational
model faithfully, but because it DOESN'T.

> If you would like to get a feel for the idea, consider how your life would
> be if the computer systems you use today were "relational".  Forget word
> processing.  Forget compilers.  Oh yes, and how many SQL interpretors are
> written in SQL?  Relational systems have a definite place in the market and
> they always will.  But don't expect them to get you to Brooklyn.
[Spelling: it's interpretEr, not interpretOr.]

I don't see why I should forget compilers.  The programming language I
use most is Prolog.  Admittedly that is more (and less) than relational,
but it is ideally suited to writing compilers.  Our Prolog compiler is
written in Prolog, and while a lot of it is recursive marching down
lists and such, there are a lot of tables in it.  There are supposed to
be ADA [ADA is a trademark of the Dud UFO] programming environments
which keep information about ADA programs in relational form.  The
Interlisp programming environment has an extremely convenient tool
called Masterscope which is basically a front-end to a small relational
data base of dynamically maintained cross-reference information.
I often use UNIX tools (awk, comm, join, sort) to maintain smallish
(~10,000 records) data sets.  These tools aren't a proper relational
data base system, but they come close enough for the relational model to
be a good way to think about them.  Using a non-relational system
would be a nightmare.  Mind you, none of these things uses SQL, which
would also be a nightmare.  But then SQL =/= Relational.

Let me give you some quotations from Date's book (chapter 14):
	"it cannot be denied that SQL in its present form leaves
	rather a lot to be desired--even that, in some important
	respects, it fails to realize the full potential of the
	relational model."

	"the user may have to expand time and effort transforming
	the 'natural' formulation of a given query into some
	different, and arguably less 'natural', representation. "

	(of the built-in functions)
	"Frankly, there is so much confusion in this area that it is
	difficult to criticize it coherently."

It is important that you should not make the mistake of identifying
SQL with the relational approach.  The better you understand the
relational approach, the worse you will like SQL.