Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!infonode!tensmekl
From: tensmekl@infonode.ingr.com (Kermit Tensmeyer)
Newsgroups: comp.databases
Subject: Re: Database Comparisons
Message-ID: <1991Feb7.224441.17631@infonode.ingr.com>
Date: 7 Feb 91 22:44:41 GMT
References: <10737@pasteur.Berkeley.EDU> <1991Feb7.134634.26917@infonode.ingr.com> <10876@pasteur.Berkeley.EDU>
Organization: Intergraph Corp. Huntsville, AL
Lines: 56

In article <10876@pasteur.Berkeley.EDU> mao@eden.Berkeley.EDU (Mike Olson) writes:
>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.
>
>
>					mike olson
>					postgres research group
>					uc berkeley
>					mao@postgres.berkeley.edu


I admit that using SQL is a nice interface to doing queries but it's
not the only one available. Any standarized interface will insulate the
user from the detailed implementaion. (Isn't that why we use layers of
calls to hide implementaion from the caller?)

If you roll your own DB, then you have roll your own interface as well.

From my "limited" activities with data base, don't relational database
allow/require you to use any field as a potiential key. Access to records
is not limited to indexs only. It is speeded up by the use of indexes.
Query Optimization tries to provide some assistance is chosing access
methods.   

Many of the real world relationship involve groups of related data. While
those relationships could be expressed as joins, it may be easier to
access those data elements as sets either owned or owned by other sets.

Example, that comes to mind is my current application (that I'm not
supposed to discuss - until it's finished [Client's request]) or 
maybe genology data storage. Storing information about individuals
is great for an ISAM but maintining the relationship of father / Child
doesn't change that offen. It is more expensive to derive that relationship
by a Join and by using tagged records or Network Sets.



-- 
Kermit Tensmeyer                        | Intergraph Corporation
UUCP:     ...uunet!ingr!tensmekl	| One Madison Industrial Park
INTERNET: tensmekl@ingr.com		| Mail Stop LR23A2
AT&T:     (205)730-8127			| Huntsville, AL  35807-4201