Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!psueea!parsely!bucket!servio!penneyj
From: penneyj@servio.UUCP (D. Jason Penney)
Newsgroups: comp.databases
Subject: OODMS-RDBMS Wars (Was: Extended RDB vs OODB)
Keywords: CASE OODB
Message-ID: <161@servio.UUCP>
Date: 21 Aug 89 16:34:09 GMT
References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> <1037@unify.UUCP>
Reply-To: penneyj@servio.UUCP (D. Jason Penney)
Organization: Servio Logic Development Corp.; Beaverton, OR
Lines: 95

I have been reluctant to jump into this fray, but with the submission
by David Harrington, an ex-Servio employee, I am compelled to make a
response and some corrections.

In article <1037@unify.UUCP> dgh@unify.UUCP (David Harrington) writes:
>
>Look at Servio Logic.  It has been building GemStone for at least 5 years, and
>as of April of this year had maybe 30 systems installed -- mostly 4 user

GemStone currently has much more than 30 systems installed.  The exact size
of our install base may be proprietary information, so I can't say more than
that.  (Our salesmen might actually volunteer that information; I'm just
saying it's not my place to give it out on the net.)

As for how long we've been developing GemStone, just how long did development 
go on INGRES before 1) it became fast enough to woo people away from older
more mature technologies and 2) RTI managed to "sell" people away from those
older technologies?  That's a rhetorical question, actually.  My points are,
there is a long development cycle in databases to reach competitive performance
(we're 10 years younger than INGRES!), and the inertia of the customer base 
can not be underestimated (they've just disovered RDBMSs in the last couple
of years).

>
>systems in R&D labs.  The only reason Servio is still around is that they are
>funded by the House of Sampoerna, an Indonesian tobacco company run by a
>41-year old Chinese "Tai-Pan" named T. Pao Liem who has MUCH more money than
>he needs.  

Mr. Harrington should appreciate that Mr. Liem does not subscribe to
the short term "management by objective" that has killed the long-term
viability of many other American companies.

>GemStone has no front-end, no distributed database, no 3rd party
>developers (other than a small group of Servio employees in Alameda trying to
>build an MRP system in Smalltalk (!) that uses GS as a structure server).
>

Incorrect!  Our front ends may currently be limited (we have several front-ends,
and better things are on the way), but we currently have the best 
distribution and heterogeneity of any of the OODMS's (Object-Oriented Data 
Management System) I have seen.  (Apologies to Object Design -- I haven't seen 
their work yet.)  We currently allow applications to run on different 
(and heterogeneous) hosts, and RPC (remote procedure call) operation is 
optional -- you can link your program directly to our runtimes, reducing 
fixed overhead for a database operation to a function call.

We currently have a number of third-party developers, an OEM, and even some
industrial applications by our customers.

>They have based their marketing strategy, such as it is, on an assumption that
>the market for OODBMS, which they say is "applications requiring a LOT of
>COMPLEX data", will mature at least 5X as fast as the relational market did.
>

This information is out of date.  Recent responses by the RDBMS companies
have caused us to re-think our marketing position.  Surely the discussion
here in comp.databases indicates that the OODMS and x-RDBMS systems will
be addressing the same problem domains.  Again, I don't feel qualified to
give a "party line" on this subject, but be sure to ask us at OOPSLA in
New Orleans.

>I think the path to OODBMS is evolutionary, especially given the huge install
>base of RDBMS and applications that use them.

No argument here, at least.

Since I've been dragged into a follow-up, I would like to point out my
own personal opinion as to why an OODMS may eventually out-perform an
x-RDBMS:  Relational systems rely on "normalizing" data into separate
relations, and then joining the relations at query time to formulate
results.  OODMSs essentially pre-calculate the joins.  Applications that
are heavier on writing than reading will probably always perform better
on an x-RDBMS, because the join calculation is deferred.  Applications
that read the database more than they write it will win with an OODMS,
because the need for joins during the query is eliminated.

Arguments about in-memory caching are spurious (as others have pointed
out), because all successful databases must reduce disk accesses to
a minimum and rely on primary memory caching to achieve adequate performance.

A final note, grounding in reality:  database systems in the 90's will have
to cooperate with other dissimilar systems.  RDBMSs aren't going to vanish
(as much as I might personally hope for that) -- the investment in existing
data sets and applications is too high.   Successful OODMSs will have to
cooperate with RDBMSs (see our demo at OOPSLA) in order to achieve market
acceptance.

But please don't ask GemStone to do a join -- that's asking an OODMS to
emulate the performance bottlenecks of an RDBMS.
-- 
D. Jason Penney                  Ph: (503) 629-8383
Beaverton, OR 97006              uucp: ...uunet!servio!penneyj
STANDARD DISCLAIMER:  Should I or my opinions be caught or killed, the
company will disavow any knowledge of my actions...