Path: utzoo!attcan!uunet!wiley!trwarcadia!simpson
From: simpson@trwarcadia.uucp (Scott Simpson)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <5177@wiley.UUCP>
Date: 26 Jul 89 05:24:18 GMT
References: <5225@mtgzz.att.com> <39400049@m.cs.uiuc.edu>
Sender: news@wiley.UUCP
Reply-To: simpson@trwarcadia.UUCP (Scott Simpson)
Organization: TRW Arcadia Project, Redondo Beach, CA
Lines: 66

In article <39400049@m.cs.uiuc.edu> render@m.cs.uiuc.edu writes:
>that the big breakthrough in OODBMS work will come elsewhere.  There are 
>several indie companies working on them, and at least one (Ontologic) is 
>into it's second generation of product.  You must not assume, however,
>that the new OODBMS will be have better performance than the RDBMS for
>the kinds of applications software engineers plan.  An OODBMS has at

We have been using the first version of Ontologic's OODB called VBase.
It uses a new language invented by Ontologic called COP/TDL.  TDL is
sort of a combined data definition/procedure interface specification
language.  You define your schema with TDL.  COP is the programming
language used to write methods.  It is a superset of C including
exceptions, seamless persistent objects and triggers.  (By seamless, I
mean persistence is a part of the language.  It is not embedded (like
ESQL) or procedure calls).  VBase also supports meta-data.  Types are
first-class objects too.
	Unfortunately, Ontologic discovered that the market is too
resistant to the introduction of a new language so they have dropped it
and introduced a C++ version called OB2 that uses procedure calls for
persistence.  The new version had to chuck seamlessness out the window
because they didn't want to modify the C++ language to support
persistent objects.  They also didn't write their own compiler this
time.  They decided that this was too resource intensive an activity so
now they support AT&T's cfront and Glockenspiel's compiler.
	Ontologic's claims that the big win with OODBs is the narrowing
of the semantic gap between your problem domain and your programming
language.  We don't live in a tuple world.  We live in an object
world.  Rather than mapping the whole world to tuples doesn't it make
more sense to map the world to objects?  We have found OODBs to be a
big win.  We mapped an ER model directly into objects in VBase.  The
semantic gap between our problem domain and our programming language 
was small.
	VBase had some problems though.  We found it somewhat slow for
our needs and since it is a first version, it is somewhat buggy.
Ontologic provided a debugger (somewhat like dbx) though and and SQL
interface to the database.  Also, the concurrency model was quite
flawed.  VBase and OB2 provide a component library.
	The new OB2 product is supposed to be much faster than VBase
and orders of magnitude faster than RDBMSs.  One of the reasons
RDBMSs are slow is that one object may be represented by a bunch of
tuples.  You have to retrieve and map all these tuples to get the
information on your object.  In OB2, you simply go and retrieve the
object.  Ontologic again provides an SQL interface but they have
extended it with OODB features.  Some of the extensions provide a great
speed improvement over a standard SQL syntax.  For example, you can
directly refer to objects following a path down the type tree.

	SELECT (Company.subsidiary.budget) ...

where Company.subsidiary.budget may require a relational join in an RDBMS
to retrieve that field.  In a large database, this may result in
retrieval of a lot of tuples that simply get thrown away.
	The new OB2 version also provides an improved concurrency
model.  Ontologic claims the back end is not specific to the
C++ type system and they will be providing interfaces for other
languages such as Ada and Fortran provided there is sufficient
interest.  (You can't transfer types between different language type
models though.  They haven't solved that problem.)
	A fellow coworker commented that VBase had many of the features
of object management systems such as Atherton and CAIS.  I don't how
to comment on that but it will be interesting to compare the features of
OODBs now and what people envision as object managers later.
	Scott Simpson
	TRW Space and Defense Sector
	usc!trwarcadia!simpson  	(UUCP)
	trwarcadia!simpson@usc.edu	(Internet)