Re: Mixing OO and DB
Date: Mon, 11 Feb 2008 13:42:56 -0400
Message-ID: <47b08923$0$4031$9a566e8b_at_news.aliant.net>
S Perryman wrote:
> 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.
Instance is just a synonym for variable. The dbms should choose an implementation based on value and possibly on optimization hints provided by the DBA. See specialization by constraint and generalization by constraint.
>> In relational world a function call is a join.
>
> A join on what specifically ??
One joins relations. Functions are a proper subset of relations.
>> 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.
If you say so.
>>> 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.
Sounds like a horrendous and costly way of dealing with something so simple.
[snip]
> 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.
Um, sometimes. If the order of evaluation affects the result, it becomes a logical decision that the user must understand.
>> 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.
But why would one want to?
>> 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.
I disagree. The weakness of graph based logical data models is in the model itself.
>> 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.
Not really. It is a whole class of implementations based on something somewhat similar to the relational model. It is the only commercially successful language based on any relational principles, however.
> 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 - 18:42:56 CET