Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shlump.nac.dec.com!databs.enet.dec.com!ballou
From: ballou@databs.enet.dec.com
Newsgroups: comp.databases
Subject: Re: Database Comparisons
Message-ID: <1991Feb11.145801@databs.enet.dec.com>
Date: 11 Feb 91 20:17:59 GMT
References: <10876@pasteur.Berkeley.EDU> <10737@pasteur.Berkeley.EDU> <1991Feb7.134634.26917@infonode.ingr.com>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: ballou@databs.enet.dec.com ()
Organization: Digital Equipment Corporation
Lines: 56

In article <10876@pasteur.Berkeley.EDU>, mao@eden.Berkeley.EDU (Mike Olson)
writes:
> 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.

Not necessarily.  If you use some form of encapsulation, then changing 
the implementation would not require rewriting the programs - maybe 
recompiling.

|> 	+  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.

See above.  Who said the special-purpose data manager can't be
designed correctly, so that one would not have to rewrite all programs.

|> 	+  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.

I disagree.  If designed well, a special-purpose data manager could allow the 
implementation to change, which may speed up retrieval/update.

|> [...]  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.

Or would waste his time...

Nat Ballou
DEC OODB