Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!odi!jack
From: jack@odi.com (Jack Orenstein)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug17.143431.25055@odi.com>
Date: 17 Aug 89 14:34:31 GMT
References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> <1989Aug11.143036.24703@odi.com> <1765@ethz.UUCP> 
Reply-To: jack@odi.com (Jack Orenstein)
Organization: Object Design Inc., Burlington, MA
Lines: 73

In article  cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>>With respect to the ongoing debate concerning OODBs vs extended RDBs,
>>I'd like to see proof (make that circumstatial evidence, if you prefer)
>>that an OODB which supports traditional basic DBMS features [is]
>>	[better than a relational system]
>>
>The one flaw in this request is that proof of concept can't be provided if the
>concept hasn't been defined.  I agree with Jon Krueger in that there is too
>much hand-waving in this discussion ("our system is better than yours")
>without defining the problem that is trying to be met.

Dan Weinreb and I have tried to define the concept in earlier
postings.

From Dan:

   > Unfortunately, the phase "object-oriented" is used to cover so many
   > different areas that it's hard to conduct a meaningful conversation
   > about what "object-oriented database" means.  Certainly, you can store
   > strings representing SQL strings in a relational database.  Certainly,
   > you can add "rule" and "trigger" features to a relational database
   > system.  And these are useful, and people will use them.
   > 
   > However, the introduction of these features still won't result in each
   > gate and each wire being represented as an element in the database
   > system.  The really interesting data like gates and wires will still
   > have to be stored in files in a file system, just as they are now in
   > every real ECAD system.
   > 
   > In the view of the people in the OODBMS companies, we will have
   > succeeded when there is no longer any need for a CAD/CASE company to
   > use the operating system's file system for anything at all, and when
   > the CAD/CASE tool can be written in a single, unified language, with
   > no translation between normalized relational tuples on the one hand,
   > and a programming language with its type system on the other hand.
   > And all this without performance degradation.
   > 
   > A particular requirement is that fetching a data value out of the
   > database system must be as fast as fetching a component of a structure
   > (record) in the programming language.
   > 
   > That's what I really mean by "object-oriented database system".  A
   > relational system with extra added "object-oriented features" like
   > rules and triggers, while it has its uses, does not solve the problem
   > that we are trying to solve.  Those "features" are beside the point;
   > beside our point, anyway.  These problems cannot be solved by taking a
   > relational database system and adding some new "features".

From me:

   > Based on [interviews with potential customers], we concluded that
   > there is a need for high performance for fine-grain manipulation of
   > small, persistent objects.


>1.  Relational DBs provide things necessary for a multi-user world
>(concurrency control, security, etc.) that may or may not be needed in the
>object oriented world (perhaps only a specific area [CAD/CASE]).
>
>2.  Object DBs provide things necessary in a single-user world (extreme speed)
>that may or may not be needed in the relational world.  Thus the need for
>cached objects.

CAx applications need transactions and multi-user capabilities also,
and we are building in these features. Yes, CAx needs extreme speed,
but design projects are typically carried out by teams, and the
multi-user issues are at least as important as in business
applications.



Jack Orenstein
Object Design, Inc.