Path: utzoo!attcan!uunet!wuarchive!texbell!texsun!sun-barr!sun!dcmartin
From: dcmartin@lisp.eng.sun.com (David C. Martin)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: 
Date: 17 Aug 89 14:57:03 GMT
References: <3560052@wdl1.UUCP> <411@odi.ODI.COM> <458@cimshop.UUCP> <2177@cadillac.CAD.MCC.COM> <20@dgis.daitc.mil> <2230@cadillac.CAD.MCC.COM> <3367@rtech.rtech.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: dcmartin@sun.com
Organization: Sun Microsystems, Inc
Lines: 48
In-reply-to: dennism@menace.rtech.COM's message of 15 Aug 89 16:57:35 GMT

Although this discussion has centered around the questions of the speed of an RDBMS versus
an OODBMS, one area which I think should be noted is the abilities and inabilities of each
type of DBMS to provide functionality under certain circumstances.

I believe Dennis mentioned the Postgres Papers (Rowe & Stonebraker) which discuss the
design and proposed implementation of Postgres, a next-generation RDBMS.  In Mike's
design of Postgres he took into consideration many of the "problems" of typical applications
in CA*, AI and other non-traditional DBMS customers.  Many of the new features in
Postgres were designed to improve performance (e.g. tuple fields which evaluate off-line to
produce data which can then be retrieved quickly when needed -- the canonical example,
if I remember correctly, was computing some employees list of children).

Many of the performance increases necessary for non-traditional environments can be provided
via NF**2 (non-first normal form) data, in which a field may contain an entire subtuple,
not simply a reference to another tuple in another table.  An object-oriented DBMS may
take advantage of an object's identity, i.e. its unique ID throughout all space and time,
in order to cluster data efficiently (I'm a little lost for words here, what I mean to
say is that the ID will allow the data to be located regardless of the necessity for it
being located in a particular table).

I could ramble on about speed, but the more important question is functionality.  One
of the biggest problems *I* have with traditional RDBMS (and I am sure that many 
non-traditional users also have) is the inability to provide certain functionality to
the user-community (i.e. non-traditional) with *support* from the DBMS.  For example,
if I wish to take an object-oriented language (I will use the Common LISP Object System)
and store the objects in the DBMS, I would like the backend to support the same types
of operations which the frontend provides, e.g. when I change the value of a database
field (a CLOS slot) using what is called a setf function in lisp (basically the inverse
of get), I would like the same operation to occur.  One example might be that when I 
setf the children list of an employee to no longer contain some child, I would like the
non-referenced child to be removed from the DB if it is no longer referenced from anywhere.

NOw I am sure that Dennis will tell me that he has millions of hackers banging on that
example right now :-) and perhaps even Larry and Mike will tell me I'm all wrong, but I
think that the position of most OODBMS vendors is to provide this type of extended 
functionality in the DBMS, not necessarily in frontend support systems.

dcm



--
-----
Stupidty got us into this mess; why can't it get us out? - Will Rogers
-----
David C. Martin                            arpa: dcmartin@cs.wisc.edu
University of Wisconsin - Madison          uucp: uunet!ucbarpa!dcmartin
Computer Sciences Department               at&t: 608/262-6624 (O)