Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!pmafire!mica.inel.gov!gem-hy!cdm
From: cdm@gem-hy.Inel.GOV (Dale Cook)
Newsgroups: comp.databases
Subject: Re: Database Comparisons
Message-ID: <1991Feb7.190050.449@inel.gov>
Date: 7 Feb 91 19:00:50 GMT
References: <10737@pasteur.Berkeley.EDU> <1991Feb7.134634.26917@infonode.ingr.com> <10876@pasteur.Berkeley.EDU>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Inel.GOV (Dale Cook)
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 84

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

Excuse me, but this has nothing to do with RDBMS format.  I've worked with a
non-relational DBMS system that has adhoc query capability, you don't have
to understand the structure any more than you do an RDBMS.  The particular
DBMS I refer to is ADABAS, and I would wager there are others.

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

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

Again, nonsense.
 
|> 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.
|> 

That may be true, but you haven't given us any real examples why.

The biggest advantage I have seen is that they enforce somewhat more rigor
in your data design, e.g., you can't have repeating groups.

----------------------------------------------------------------------
--- Dale Cook     cdm@inel.gov
The opinions are mine.  The following disclaimer is my employers.
----------------------------------------------------------------------
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.