Re: Object-relational impedence

Yagotta B. Kidding wrote:

> S Perryman <q_at_q.net> wrote in news:fqoenv$fo4$1_at_news.datemas.de:

>>Yagotta B. Kidding wrote:

>>>'Match' is cool, but what about more interesting operations like
>>>'project(join(R1,R2)), R1.a1, R2.b3)' where R1 is a set of
>>><c,a1,a2,a3> tuples and R2 is a set of <c, b1,b2,b3> tuples ? How
>>>do you express that in your fav OO language ?

>>As I have said on numerous occasions, the semantics of "joins" are an
>>issue for OO (specifically the fact that in OO any of the "values" of
>>c/a1..a3/b1..b3 could be a computational operation and not a data
>>value etc) .

> Does "the semantics of "joins" are an issue for OO" mean that relational > joins cannot be implemented in principle in an object-oriented way ?

IMHO most things can be implemented in principle. Efficiency etc is another (important) matter.

Thinking out loud ...

My unease about joins is that in the ADT/OO sense, for your example etc we effectively create instances of a new type whose properties actually belong to multiple (existing) object instances. Properties that may be realised as computational operations.

I feel that prevailing impls of OO are not up to the job of doing the above (although having a consistent Relational infrastructure that apart from joins - works is and is programmed the same way for both ADT-based and "data value only" types/tuples - is something I have long wanted) .

I similarly feel that Functional programming may have the answers to the problems (the execution engines in particular) .

But thinking out loud and "feeling" is hardly knowing (one way or the other) is it. :-( :-)

Regards,
Steven Perryman Received on Thu Mar 06 2008 - 17:36:36 CET