Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug11.155020.25059@odi.com>
Date: 11 Aug 89 15:50:20 GMT
References: <408@odi.ODI.COM> <3560053@wdl1.UUCP>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 40
In-reply-to: mitchell@wdl1.UUCP's message of 11 Aug 89 00:56:13 GMT

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).  It also 
   makes sense that adding another layer would make a slower
   system - comparable to an extended rdbm.

That's right, by my definition of "object-oriented DBMS".  Although a
relational database system can be enhanced with many features that are
often associated with "object-orientation", the kind of DBMS needed by
CAD/CASE/CAP/etc systems for "high performance for fine-grain
manipulation of small, persistent objects" requires a totally
different underlying storage architecture.  Bruce Speyer's point about
the high cost of switching address space/process context is quite
right; this is one of the important factors.

(The relational database fans will point out that there are drawbacks
to using the application process's address space, mainly that
application bugs causing "wild stores" can damage data.  Yes, that's
true; it's a tradeoff.  It's not all that much worse than the current
situation, in which application bugs can write garbage to files.)

   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?

No, Prolog and "deduction" don't have much to do with the goals that
we're trying to achieve for CAD/CASE/etc. systems, although these
ideas are interesting and useful for their own domains.  Generally, we
see a need for seamless integration with the underlying programming
language.  The language in question, for our applications, is C++; the
CAD and CASE vendors have made it clear that C++ is what they want.
So C++ must be the starting point.  Then it's possible to go beyond
C++ to provide access to things that a database system does well, such
as queries over sets and representations of relationships.  This is an
area that's still being explored.

Dan Weinreb		Object Design, Inc.		dlw@odi.com