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)