Re: Object-relational impedence

On Mar 5, 9:31 am, S Perryman <q..._at_q.net> wrote:
> Marshall wrote:
> > On Mar 3, 8:52 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> >>I was hoping perhaps people might be able to offer
> >>perspectives on the issues that they have encountered.
> > Another big difference:
> > Object oriented languages work in object-at-a-time terms.
> > Even when those objects are collections, if one wants to
> > operate on every object in the collection, one iterates
> > over the objects in the collection and calls methods on
> > those objects one at a time.
> > The relational model works in set-at-a-time terms. One
> > operates on entire sets at once.
>
> This is a fallacy.
> In any system, if I have a set S of tuples (x,y) , and request the
> following :
>
> { e IN S : e.x = 123 }
>
> I have to examine each tuple in the set to find those that satisfy the
> predicate. The satisfying tuples do not appear by magic.

I don't understand what point you're trying to make here. Are you talking about the language or the implementation?

You use set-builder notation to describe a set. In the relational model, something very nearly identical would be used. It is a single set-oriented expression. In an OOPL, one would iterate over a collection. Inside a loop, one would find expressions or statements written against single objects. The semantics might be the same; the languages are different.

> > The two don't fit together very well.
>
> Particular *implementations* of OO prog langs may not fit well with a
> relational execution engine. But some (OO implemented on Functional
> programming infastructure etc) fit very well ( "lazy" programming
> etc) .

Again, I don't understand what you're trying to say. I am discussing differences at the language level, not implementation differences. Yes, we could implement either a relational or an OO language with a functional SSA intermediate language; this doesn't affect what the abstractions of that language are, or whether they are set-oriented or object-oriented.

Also, lazy vs. strict seems a completely orthogonal issue; I don't see why you bring it up.

As an *implementation* point, when one puts the two different kinds on languages on the wire, one gets two different sorts of performance characteristics. These characteristics heavily favor set-oriented language. This isn't *necessarily* the case, true, but it is *actually* the case in every circumstance I'm aware of.

Marshall Received on Wed Mar 05 2008 - 19:42:15 CET