Re: Mixing OO and DB

Tegiri Nenashi wrote:

> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:

SP>For me, the big problem has always been the following :

SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)

SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;

SP>In the OO world, the problem is that for each instance of SomeType held
SP>in Somewhere, the *implementation* of the property 'x' could be merely
SP>an actual data value, or a serious computation process. That is the ADT/OO
SP>way.

> If x is computed, then why don't you introduce a function that computes it?

We have.
A function whose implementation may be different for every instance of Sometype that is contained by Somewhere.

> In relational world a function call is a join.

A join on what specifically ??

> If this function is not known at runtime
> then what logic is involved in selecting it?

You will have to clarify what you mean here.

> Can't the problem solved by dynamically constructing this query?

The time of query construction is irrelevant.

>>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.

> What is SELECT? The whole query? The projection part? You OO guys
> perfected the art speaking gibberish.

As in the SQL construct ??

Or if you prefer ... s = { e IN Somewhere : e.x = 123 }

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

> Function is just a relation with functional dependency. It works
> pretty much like an index. When a function is called from a query, it
> is essentially a join, although there is no ambiguity which order this
> join is evaluated.

The "order" of evaluation is an *implementation* decision.

> Therefore, in principle, FP is too weak to embrace
> relational. It is more likely to happen the other way.

FP is perfectly capable of accommodating RA. Because RA is based on mathematical concepts, as is FP.

Therefore any computable predicate expressible in RA, can be expressed in FP.

> Relational programing has its weaknesses, but they are not what OO
> propellerheads think.

The weakness, as with all things, is in the *implementation* of the concept. No better demonstrated than SQL for databases, and C++ for OO prog langs.

> One missing part in the relational is formal
> grammars and languages. The underlying theory of grammars and language
> theory is Kleene algebra which is incompatible with RA. Witness how
> regular expressions are integrated into SQL

SQL is a *specific implementation* of the relational model is it not.

There is nothing inherent in the relational model, or regexps, that prevent the latter being defined in terms of the former (ie confirming my comment above about implementations) .

Regards,
Steven Perryman Received on Mon Feb 11 2008 - 17:30:19 CET