Re: Mixing OO and DB

From: Dmitry A. Kazakov <>
Date: Fri, 8 Feb 2008 20:32:03 +0100
Message-ID: <>

On Fri, 08 Feb 2008 16:44:53 +0000, S Perryman wrote:

> Dmitry A. Kazakov wrote:

>> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:

>>>I think it might be interesting to explore the whole concept backwards:
>>>start with the idea that a table is just a specific class of object

> In an RDB, a "table" T is more than that.
> It also represents the extent set (all instances) of T.
> Then we have issues coming from the semantics of relational algebra.
> For example:
> In an object type system, what would the semantics of "joins" be ??
> Should it have the same semantics as the relational model (a new type
> tuple etc) ?? Or something else ??
> If so, how would this new type be implemented/realised in the underlying
> system (closures etc) when the join is done on two different object
> instances ??

The same problem exists with any algebra less flat than numeric fields. What is the type of Matrix x Matrix? What is the type of Velocity / Duration? etc. The problem is rather fundamental and appears when we deal with operations built on tuples of types.

The point is though that there is nothing in RA to deserve a special treatment. That is actually is not an option, because we just cannot provide a tailored solution for each and ever algebra.

> >Then come up with two things: how to store persistent objects and
> >retrieve them when
> >necessary without regard for any data model; and how to get tables and
> >application objects to collaborate on common objectives.
> For me, the big problem has always been the following :
> SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
> s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
> In the OO world, the problem is that for each instance of SomeType held
> in Somewhere, the *implementation* of the property 'x' could be merely
> an actual data value, or a serious computation process. That is the ADT/OO
> way.
> If the implementation is a computation process, there is also no guarantee
> that each instance in Somewhere actually use the *same* implementation.
> So all the optimisation etc that is achievable when you constrain x/y/z to
> be raw data values only, is lost when you can no longer presume such
> constraints.

I see it different. First the above should be decomposed into primitive operations over the types involved. There is at least the type of the table and one of the cell. If SELECT were doubly dispatching, then one could certainly provide different implementations for different combinations of types.

To me a bigger problem is that RA is "computationally instable" in the sense that a minor variations of same constructs may have massive effects on resources consumptions, i.e. distributed overhead. OO tries to localize effects by decoupling and encapsulation.

> It is because of this that I believe that the only paradigm that is capable
> of providing the true engine for a relational info base that caters for
> both OO and current RDBMS, is Functional programming (data values and
> computation entities - functions - are treated the same, techniques such as
> lazy evaluation, "copy on write" behaviour etc) .

Doesn't it just postpone the problem until run-time?

> With imperative prog langs (C, C++ , Java etc) , I can never see the
> "mismatch impedence" ever being overcome. :-(

That would be unfortunate, because I see a general problem with declarative approaches as they try to sort things out per means of "magic." Without magical devices at hand, we should design them by themselves. How?

Dmitry A. Kazakov
Received on Fri Feb 08 2008 - 20:32:03 CET

Original text of this message