Re: Mixing OO and DB

On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> The same problem exists with any algebra less flat than numeric fields.
> What is the type of Matrix x Matrix?

Speaking of matrices, what do you possibly achieve by bundling together the multiply(Matrix,Matrix) function together with the Matrix data structure (other than loosing the symmetry: consider matrix1.multiply(matrix2) method call how ugly is that)? Perhaps you want a convenient listing of all the functions that have Matrix as a first argument? Such a query shouldn't be a problem in any of contemporary IDEs which *are* databases storing the source code. Or you imply that you can define Matrix2x2 and subtype it into GeneralMatrix? How silly is that (given that it is just simpler to write general implementation). Or maybe one is advised to subclass the other way?

If you serious about working with matrices (or any math) in your application, then you design a mini-language which looks as Maple, Matlab, or Mathematica.

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

You mean you don't want to, or you are not qualified to?

> > 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 x is computed, then why don't you introduce a function that computes it? In relational world a function call is a join. If this function is not known at runtime, then what logic is involved in selecting it? Can't the problem solved by dynamically constructing this query?

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

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

You mean optimization? This is true, query optimization in relational world is far more advanced than the one in the procedural programming (which includes OO), and therefore it has more challenging problems.

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

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. Therefore, in principle, FP is too weak to embrace relational. It is more likely to happen the other way.

Relational programing has its weaknesses, but they are not what OO propellerheads think. 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, as if there is no common operation in relational algebra and algebra of strings... Received on Fri Feb 08 2008 - 22:18:05 CET