From: Eleanor McHugh <eleanor@...>
Date: 2007-03-29T18:34:07+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Sci

On 29 Mar 2007, at 03:56, Daniel DeLorme wrote:
> Austin Ziegler wrote:
>> Sorry, Daniel, but you didn't show anything. You *claimed* that
>> they're similar; you conflated things that have no relationship
>> whatsoever.
>
> It might be impudent of me but have you considered that just maybe  
> *you* are the one who can't *see* the relationship? But you are  
> right I didn't show anything. Just take any ORM layer and the fact  
> that you can directly and easily map a SQLDB to an object model is  
> all the proof I need that a RDBMS *can* indeed be expressed as an  
> object graph and that an OODB can therefore be relational.

No, this demonstrates that an OODB can be implemented in terms of an  
SQLDB. This in no way demonstrates that the converse is true. Much of  
the point of an OODB is to capture a given object hierarchy, which is  
essentially a constrained Entity-Relationship model - the most  
obvious constraint being the relaxation of normalisation conditions.

Personally I want each item of data to occur once - and only once -  
in my database, as that way I can ensure that a single change is  
reflected universally and performed efficiently. I also want the  
flexibility of joins to composite new views of my database based upon  
whatever arbitrary query conditions I need fulfilling, and yet again  
I want that process to be efficient and to guarantee that all data  
returned is universally accurate and consistent at the instant that  
the query is performed. Everything else I can do in software.

My measure of efficiency in this case would be based upon individual  
data store reads, as for any significant data-set that will be the  
primary constraint on my application's performance. Compositing  
objects at run-time will be many orders of magnitude faster than  
loading the data from persistent storage.

> It's now clear to me that we are arguing about different things;  
> you about the (hierarchical) OODBs that you know and I about the  
> (relational) OODBs that I can imagine. In the end, I believe OO is  
> more about the physical model than the logical model of data.

Which is its shortcoming. If you model data based upon a physical  
structure, you then need to optimise your database engine to suit  
that structure. Taking the relational path and putting logical  
structure first leads to an implementation that is optimised for  
general queries, not just the specific queries embodied in a given  
object model.

Think of the relational model as a scientist's take on data, where an  
OODB would be an engineer's.

The scientist is interested in the general properties of data itself,  
with the nature of individual data items being an implementation  
detail - sure they add character to the problem space, but they don't  
really further one's understanding of it's geometric principles. The  
fact that the relational model is a process-oriented implementation  
of Occam's Razor sits well with this view.

The engineer of course is more concerned about getting "this damn  
thing I'm building now" to work and often cuts a few corners where  
theory is concerned. Fine, do that in your software if it makes  
sense, but don't do it with your data model: it's the underpinning of  
not only your application, but of every other application that needs  
access to the same data-space, so generalising the model at a later  
date will be the most expensive change you can make.


Ellie

Being and Doing are merely useful abstractions for the 'time'- 
dependent asymmetries of phase space.