On 3/31/07, Clifford Heath <no / spam.please.net> wrote:

> Yes. Relations are the right way to store data, objects are the
> right way to manipulate them, but facts are the right way to conceive
> of them, and hence to query them. Both ER and OO schemata are absorptions
> of fact-based schemata to suit the physical characteristics of disk
> storage and RAM storage/allocation respectively. IOW they're both
> derived, to some extent contrived, for different purposes. Neither
> can ever be the "one true way".

And there's a fundamental tension between the driving ideas of a
database and object oriented programming.

Databases come from a philosophy of separating data and it's
representation from the programs which operate on it. In the case of
relational databases, that representation is encapsulated behind an
interface defined by SQl.

To many this separation is the sine qua non of what it means to be a database.

On the other hand, Object Oriented Programming comes from the
philosophy that the representation of the data in an object should
only be known by the methods which operate on that object.  Alan Kay's
conception of an object was that it was a tiny completed von Neumann
computer with data and code co-located and encapsulated from the other
objects with which it interacts behind an interface defined by its set
of methods.

From the traditional point of view, one could consider the term Object
Oriented database to by an oxymoron, since the data representation is
not hidden from the objects which represent the data in the database.
These folks might look at OO db systems and see them as  shared
persistent object stores but not a databases.

Of course if you look at an OODB from the point of view of the
interface between client objects and database objects, the OO
encapsulation does provide that separation.  The complaint then is
that the database representation of the persistent objects is not as
portable as a more "standardized" database.  This is often a valid
point, when a requirement exists for interfacing with code outside of
the object system.

ORM approaches like ActiveRecord (and the pattern it's named after)
provide an Object Oriented interface on top of a standard relational
model.  The active record objects provide oo encapsulation between the
DB and the rest of the code, and SQL provides the DB encapsulation
between the active record objects and the actual database engine.  Of
course, the encapsulation of the OO system can be broken because code
other than the active record objects can directly access and alter
their state via SQL, but that's often an requirement, and knowing this
the issue can be dealt with.

It seems to me as if the all out war between the proponents of OO dbs
vs. the relationalists which raged in the mid-1980s to mid-1990s has
toned down quite a bit since then.  Tying this to the title of the
thread, I'd say compare OO DBs and Relational DBs to North and South
Vietnam (in no particular order). For the most part the users of these
technologies are now living in a land where the communist and
capitalist approaches have merged, and things are quite a bit more
peaceful.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/