Path: utzoo!attcan!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug17.180727.28121@odi.com>
Date: 17 Aug 89 18:07:27 GMT
References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> <1989Aug11.143036.24703@odi.com> <1765@ethz.UUCP>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 63
In-reply-to: marti@ethz.UUCP's message of 15 Aug 89 07:31:50 GMT

In article <1765@ethz.UUCP> marti@ethz.UUCP (Robert Marti) 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 such as
   concurrency control, transactions, set-oriented data manipulation,
   the ability to define views and to dynamically add new tables/columns,
   etc. is

   1) faster than a relational system for typical technical/engineering
      applications than a relational system, and

The proposition is that for certain applications, i.e. when being used
certain ways in certain computation environments, we believe that the
approaches that we're taking will result in substantially higher
performance than using a relational database system in those same
circumstances.  So there are two problems.  First, it all rests on
what sort of benchmarks you use, i.e. it depends on what you are
trying to test.  Second, it's not a claim about existing systems, but
about what some of believe we can accomplish.

   2) not much slower than a relational system for traditional business
      oriented applications.

Actually, I'm sure that some of the OODBMS's indeed *will* be much
slower than relational database systems for traditional business
oriented applications.  I, for one, certainly do *not* belive that the
kind of OODBMS that I am working on is going to replace, subsume or
displace relational database systems.  There are plenty of fine
relational database systems in existence.  They were designed to do a
certain kind of job, and they generally do those jobs fine.  When I
talk about object-oriented database management systems, I mean a
substantially different kind of DBMS designed to deal with a different
kind of problem, with different needs and tradeoffs.  (There are other
OODBMS efforts that might not take the same position, so let me
emphasize again that I'm speaking for myself.)

   How about some benchmarks, controversial as they may be?

If I had in front of me the sort of OODBMS that I envision existing in
the near future, I am sure that I could devise benchmarks that would
make the OODBMS look far faster than the RDBMS, *and* vice versa,
simply by designing the benchmarks with that goal in mind, because the
two systems would be so different.  So a benchmark would not "prove"
that system A is N times the speed of system B, but rather would
illustrate what sort of things each system is particularly good at.
That is, the interesting result would not be the numerical wall clock
times, but rather the general assumptions and philosophy underlying
the design of the benchmark.

I've been trying to think of a good analogy.  Suppose we benchmark a
car against a motorboat; the real question is not which one was
faster, but whether the benchmark took place on the interstate or on
the lake.  In my view of OODBMS, we are talking about two different
tools for two different jobs, and so a direct benchmark isn't really
relevant.  When some of us talk about "superior performance of an
OODBMS" or something, what we are really trying to say is that there
are interesting new data management tasks that are quite unlike
traditional business (DP, MIS) applications and for which existing
relational systems would not perform well.  I hope this makes
everything more clear than my previous postings.

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