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.