Re: Object-relational impedence

On Mar 15, 12:16 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
>
> > That's why the OO camp has such problems with making a good ORM. If
> > SQL would have been low-level, compared to the network model, the task
> > would have been much easier.
>
> Not necessarily. Certain architectures are difficult to translate into, for
> vector processors. It is related to the presumption of computational
> equivalence. A difficulty or impossibility to translate can come from
> weakness of a given language. SQL is pretty weak.
>
> Clearly when SQL is used as a intermediate language for an ORM, then to
> have it lower level and more imperative than it is would be an advantage.
>
> But I agree that ORM is wasting time. In my why other architectures are
> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
> a concept.

I expect you like the idea of distributed OO, orthogonal persistence, location transparency and so on. However the literature is hardly compelling. There is the problem of

• finding a consistent cut (ie that respects the happened-before relation)
• the contradiction between transactions and orthogonal persistence
• the contradiction between rolling back a transaction and orthogonal persistence
• the impossibility of reliable distributed transactions
• the fact that synchronous messages over the wire can easily be a million times slower than in-process calls
• the fallibility of distributed synchronous messages which contradicts location transparency
• the enormously difficult problem of distributed locking
  • how to avoid concurrency bottlenecks
  • when to release locks in the presence of network or machine failures
  • distributed deadlock detection.
  • rolling back a distributed transaction.
• how to schema evolve a distributed OO system assuming orthogonal persistence and location transparency.
• how to manage security when a process exposes many of its objects for direct communication with objects in another process.

Persistent, distributed state machines raise more questions than answers. Persistent distributed encoded values provide a much better basis for building a system.

SOA suggests that a large system should be decomposed by behaviour (ie "services") which is basically an OO way of thinking. It is a flawed approach to the extent that it is promoted as the main way to build enterprise systems. The only proven scalable approach is to remain data-centric at ever increasing scales.

The easiest way for distributed applications to communicate is indirectly via shared data rather than by direct communication. This is implicit with a data-centric approach.

The WWW is data-centric. It is not at all surprising that Http on port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put together. Http concerns messages used to access data instead of messages used to elicit behaviour. Received on Sat Mar 15 2008 - 02:59:49 CET