Re: Mixing OO and DB
Date: Fri, 8 Feb 2008 20:32:03 +0100
Message-ID: <1oje16zltqtn1.ysvl3v9gk409.dlg_at_40tude.net>
On Fri, 08 Feb 2008 16:44:53 +0000, S Perryman wrote:
>> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:
>
>>>I think it might be interesting to explore the whole concept backwards: >>>start with the idea that a table is just a specific class of object
>
> In an RDB, a "table" T is more than that.
> It also represents the extent set (all instances) of T.
>
> Then we have issues coming from the semantics of relational algebra.
>
> For example:
>
> In an object type system, what would the semantics of "joins" be ??
>
> Should it have the same semantics as the relational model (a new type
> tuple etc) ?? Or something else ??
>
> If so, how would this new type be implemented/realised in the underlying
> system (closures etc) when the join is done on two different object
> instances ??
The same problem exists with any algebra less flat than numeric fields. What is the type of Matrix x Matrix? What is the type of Velocity / Duration? etc. The problem is rather fundamental and appears when we deal with operations built on tuples of types.
> >Then come up with two things: how to store persistent objects and
> >retrieve them when
> >necessary without regard for any data model; and how to get tables and
> >application objects to collaborate on common objectives.
>
> 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 the implementation is a computation process, there is also no guarantee
> that each instance in Somewhere actually use the *same* implementation.
>
> So all the optimisation etc that is achievable when you constrain x/y/z to
> be raw data values only, is lost when you can no longer presume such
> constraints.
> 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) .
Doesn't it just postpone the problem until run-time?
> With imperative prog langs (C, C++ , Java etc) , I can never see the
> "mismatch impedence" ever being overcome. :-(
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Fri Feb 08 2008 - 20:32:03 CET