From: JONNALAGADDA Srinivas <srinivas.j@...>
Date: 2007-03-29T17:14:17+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Sci

On 29-Mar-2007, at 07:20, Austin Ziegler wrote:

> As I was discussing with someone off-list, the data that I need for a
> customer report is very different than the data that I need for a
> summary of how many customers bought a particular widget and how often
> in which locale.

We do such analyses (a good variety of them) in stock portfolio  
management, several hundred times a day.  The 'anchors' of such  
search are very ad-hoc in practice.

Fund managers, who typically do not have programming skills, sit with  
programmers to interactively build hyper-cubes with arbitrary classes  
-- and their attributes -- as dimensions.  We have several such 'cube  
terminals' open in front of us.  Minute-by-minute decisions are made  
based on analyses of such cubes.  Typical number of individual  
objects read during an analysis ranges between 1.5 and 20 million.   
On our 833 MHz UltraSparc server, most of them take under 10 seconds!

> Object databases force you to query for a full object
> even if you need a tiny portion of that object. In the putative
> example I describe above, I only need to know a customer's locale
> (state or province, if you prefer) -- but with an object database I
> have to restore the entire customer object before I can then whittle
> down the data to exactly what I need.

Not necessary -- partitioning techniques, vertical partitioning in  
particular, have long been (as in, for over twenty years) used in  
some object databases.  In Vision, for instance, an opaque object  
stub is what is returned upon object retrieval.  Which parts of the  
object 'actually' get loaded is dependent upon access; however, the  
developer is unaware of this (the 'opaque' part).

A variety of collection classes (examples include lists, indexed  
lists and time-series collections) are used to model relationships  
between different classes.  Navigation uses the keys of such  
collections.  Back references are established, where needed,  
similarly to foreign keys in RDBMSs.

Over the years of such every-day-hundreds-of-ad-hoc analyses, I have  
not felt constrained to hierarchically navigate anything at all!

One point where I agree with you is that most such systems are vendor- 
specific.  Vision, for instance, provides only one way of accessing  
information -- through a dialect of Smalltalk.

Greetings,
JS