Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!apple!vsi1!daver!athsys!jim
From: jim@athsys.uucp (Jim Becker)
Newsgroups: comp.databases
Subject: Re: relational vs object-oriented
Message-ID: <243@tityus.UUCP>
Date: 16 Feb 89 22:59:44 GMT
References: <3900005@m.cs.uiuc.edu>
Organization: Athena Systems, Inc., Sunnyvale, CA
Lines: 24


	Athena has implemented an object-oriented database for our OO
product. We store the actual instances of the classes and data
structure objects into the database intact. One thing that this has
shown is that the process to upgrade or change the class definitions
of the objects results in an entire schema change and upgrade process
for the entire database. Meaning that the modification of a single
class definition results in an upgrade problem/path that must be
addressed before databases created prior to the modification can be
used. Also, all databases used must be used against the exact matching
software (classes have to matchup exactly). 

	Note that this problem only would exist during the development
process, not once in the field. This problem can also be aggravated by
something as simple as a compiler change or upgrade, if this results
in a different layout or structuring of the data elements.

	I'm not a relational database expert, but they seem to be
disjoint enough that it is fairly easy to adjust the various fields
and add or subtract new fields. They also appear simplier to
reconstruct and manage.  In our approach to OO database design and
usage this has not proved to be the case.


-Jim Becker	...!sun!athsys!jim