From: mao@olympus.CS.Berkeley.EDU (Mike Olson)
Newsgroups: comp.databases
Subject: Re: Relational Systems set back DP by at least 10 yrs.
Date: 10 Apr 1992 16:31:08 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: olympus.cs.berkeley.edu

in <12109@tamsun.tamu.edu>, chandra@cs.tamu.edu (Chandrasekaran Periannan)
posts a copy of a letter submitted to cacm by henry g. baker.  i'm a
researcher in relational systems, and have worked for a relational
database systems vendor, and so may be safely considered a relational
database bigot.  i think they're great, and that baker is miles off
base.

baker's fundamental claim is that ISAM and other predecessors of relational
systems outperformed current-generation relational systems because a
knowledgable programmer could hand-tune applications to use the fastest
access path available.  this is a red herring.  all commercial relational
systems of which i am aware allow the user to submit a query plan, rather
than a query string, if desired.  this lets programmers who really care
choose the access path they know to be fastest, without interference from
the query optimizer.

more importantly, a query optimizer for ad hoc queries means that it's
not necessary to write a fortran program in order to answer every question
you want to pose to the database.  the arrival of relational systems in
the 1970s forced the world to acknowledge that query optimization was
automatable.

baker also claims that ISAM correctly handled the parts explosion
problem, and that relational systems were incapable of doing so.  in
the early years, this was certainly true; it was impossible to formulate
a recursive query in the languages provided by commercial relational
systems.  however, the model is not inherently flawed; codd's new book
(Codd, E. F., _The_relational_model_for_database_management_:_version_2_,
Reading, MA, Addison-Wesley, c1990) solves the parts explosion problem.
postgres has supported recursion in the query language for a couple of
years.

now, neither the features cited by baker (hand-optimizability) or by me
(auto-optimizability) are inherent in either the ISAM or the relational
model.  non-relational systems can have ad-hoc query languages and
query optimizers, and relational systems can allow query planning to be
short-circuited.  similarly, neither model prohibits the expression
of recursive queries.  so what are the advantages of the relational
model?

the primary benefit of formalism is to tell you what the right answers
are.  codd's contribution was in abstracting the data's representation
from its semantic properties.  in particular, programmers did not need
to understand the layout of data on disk; they could formulate queries
in a high-level language, and the execution engine would carry them out.
because of the rigorous formalism of the model, a query would return the
same answer regardless of the access path chosen for it.  deterministic
behavior is in general desirable, and relational systems were the first
systems on the commercial scene to try to provide it.  to the extent
that they don't, they're not relational, but that's another crusade
entirely.

of course, theory's all well and good, but baker buttresses his argument
with years of commercial experience.  i'll come out of the ivory tower
for long enough to dispute him on that point, as well.  if relational
database systems are in fact the unmitigated disaster that he claims,
why have they been so successful?  i claim that most relational systems
are easier to use than most ISAM systems.  they're faster to program,
more flexible in allowing the user to add new data tables and dependencies,
and easy to learn to use.

i don't buy the argument that businesses have been hoodwinked into
accepting second-rate technology by a bunch of devious university
researchers.  most successful businesses are run by people smart
enough to understand their problems and the best solutions to them.
the fact that relational systems are so widely installed demonstrates
that baker is just plain wrong.

					mike olson
					postgres research group
					uc berkeley
					mao@cs.berkeley.edu