Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!odi!indirect!jack
From: jack@odi.com (Jack Orenstein)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Summary: Born-again DBMSs won't cut the mustard
Message-ID: <411@odi.ODI.COM>
Date: 9 Aug 89 17:37:18 GMT
References: <3560052@wdl1.UUCP>
Sender: news@odi.com
Lines: 44

In article <3560052@wdl1.UUCP>, mitchell@wdl1.UUCP (Jo Mitchell) writes:
> 
> 
>   For those of us who are interested in CAD/CAM, CASE applications ...
> 
>   After watching the oodb action and "extended" rdb action for awhile I'm
>   of the opinion that all the extended rdb's will eventually turn into an
>   oodb (at least at the conceptual level).
> 
>   Because of this it seems most application developers will decide to "convert"
>   via the route with the least slope - by staying with an evolving rdb...
 
I assume that by "extended rdb" you mean a relational database system
that permits instances of object classes to be stored in fields of
tuples, instead of just numbers and strings.

There are different kinds of application developers, and they will
have different paths to (or around) DBMSs.  An important question is
what are these developers doing about persistent storage now?  Some
CAx application developers store data in DBMSs, using "long fields",
in which they can dump and then retrieve byte strings that have to be
interpreted in the application code. Retrieval based on the content of
such fields is possible only to the extent that other int or string
attributes store summary information.  An extended relational DBMS can
certainly be built on top of a long field facility, and it would be
surprising if a number of relational DBMSs did not go this route,
turning their relational systems into "born-again" OO DBMSs. This
would probably be appealing to CAx developers who are currently using
long fields.

On the other hand, many CAD/CAM and CASE developers have bypassed
relational DBMSs due to performance problems.  Such people have built
their own, or have built on top of file systems. Since these users are
not using any DBMSs currently, I don't agree that the proposed
conversion scenario applies to them. Many users who have gone this
route are becoming aware that OO DBMSs will meet their requirements
for expressiveness, integration with the host language and, maybe most
importantly, performance. I don't think that such users will be
convinced by a thin layer of paint on top of something they considered
and rejected before.


Jack Orenstein
Object Design, Inc.