Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!odi!jack
From: jack@odi.com (Jack Orenstein)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug11.191834.14669@odi.com>
Date: 11 Aug 89 19:18:34 GMT
References: <408@odi.ODI.COM> <3560053@wdl1.UUCP>
Reply-To: jack@odi.com (Jack Orenstein)
Organization: Object Design Inc., Burlington, MA
Lines: 57

In article <3560053@wdl1.UUCP> mitchell@wdl1.UUCP (Jo Mitchell) writes:
>
>	So does this mean an object oriented dbms can not, by performance
>	necessity, be built above a rdbms?  (If performance is the key, than
>	an oodbms built in such a manner would require some heavy duty
>	optimization - the joins would be incredible).

That's my opinion, anyway. Think of the relational schema that you'd
use to represent a circuit. Every time you wanted to follow some
connection, e.g. from a pin to a wire, a join would be required. To do
any useful work, e.g. a circuit simulation, a very large number of
joins would be required. Not only is there a big join optimization
problem, but the efficiency of the join implementation is crucial.

In an OO DBMS schema, the connections would be represented by
pointers, and following a pointer can be done extremely quickly, on
the order of a few machine instructions. Following a pointer will be
faster than a join (amortized over the number of connections made by
the join), no matter how the join is implemented, (judging by the
algorithms currently available).

This is why I believe that a relational DBMS (or an OO DBMS built on
top of a relational DBMS) cannot deliver the performance required for
dealing with large numbers of small objects. 

>
>	Now, if the oodbms is not built above the "proven" relational algebra
>	what should it be built above? Prolog? Now what are we talking about?
>	Object-oriented DBs or deductive DBs?

I don't see how Prolog enters the picture.

Many OO DBMSs start with a programming language and add persistence
and possibly semantic data modeling constructs.  Of the "first
generation" OO DBMSs, Vbase started with an extension of C, GemStone
started with Smalltalk, and Statice started with Lisp. Object Design
and other "second generation" companies are starting with C++.  The
advantage of this approach is that application developers no longer
have to worry about two type systems (one for the host language and
one for the DBMS) and two namespaces. Also, the problems inherent in
translating complex objects between host language structures and
relations in the database disappear.

CAx developers are in such a difficult position because they need the
expressiveness of a general-purpose programming language, and the
persistence, atomicity and recoverability of DBMSs. DBMS query
languages aren't expressive enough, and languages offer very little in
the way of persistence and nothing to support atomicity and
recoverability.  Most of the CAx developers we've talked to have
resolved this problem by using a programming language and then
providing their own persistence on top of file systems.  The goal of
an OO DBMS provides the best features of general-purpose (OO)
languages and DBMSs in a single package.


Jack Orenstein
Object Design, Inc.