Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!shelby!agate!pasteur!eden.Berkeley.EDU!mao
From: mao@eden.Berkeley.EDU (Mike Olson)
Newsgroups: comp.databases
Subject: Re: Database Comparisons
Message-ID: <10876@pasteur.Berkeley.EDU>
Date: 7 Feb 91 16:36:36 GMT
References: <10737@pasteur.Berkeley.EDU> <1991Feb7.134634.26917@infonode.ingr.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@eden.Berkeley.EDU (Mike Olson)
Organization: University of California, Berkeley
Lines: 51

In <1991Feb7.134634.26917@infonode.ingr.com>, tensmekl@infonode.ingr.com
(Kermit Tensmeyer) writes

> Personnally, I don't see that much need to real relational databases. Most
> of the applications that I see in the real world use the database as
> complicated ISAM files. Network Databases seemed to use the resources more
> efficently.

> I suspect that the idea of Relational Data format is more sexier to managers
> than the other types of databases.  Is there any real world advantage to
> RDBMS?

if your application is cast in concrete, it may be better to write a
special-purpose data manager.  flight reservations is an example of an
application area that's been pretty successful at doing non-relational
data management commercially.

however, there are several drawbacks:

	+  NO ad-hoc queries.  if you want to get some data out of the
	   database, you have to understand its structure and write a
	   program.

	+  you're not insulated from changes in the the storage structure.
	   if i change the way that records are organized on the disk (a
	   thing that i might do, for example, to speed up certain types
	   of searches) you have to rewrite all the computer programs that
	   use the database.

	+  as a corollary to the last point, there's no simple way for you
	   to speed up a query short of recoding the program that implements
	   it.  on a relational system, i can just define an index and let
	   the optimizer do the right thing.

in general, query optimizers have proven to be about as good as competent
programmers in picking the right query.  a programmer with extra information
about the data on the disk can sometimes do better than an optimizer, but
the additional cost of programming every query by hand has to be considered
as well.  finally, all the commercial people are claiming that we're on
our way to twenty-way joins.  i don't really believe that, but if it's
true, then the programmer does not exist who can hand-optimize the query
in finite time.

in short, relational systems have a substantial advantage over network and
hierarchical database systems for common business applications that involve
ad-hoc queries and frequent schema changes.

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