Re: Object-relational impedence

On Mar 4, 11:05 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
> >
> > Furthermore, since OOPLs lack physical independence, traversing
> > the graph may be quite expensive, particularly in the case where
> > the graph is backed by storage in a database, which is part of
> > why ORM is such a universally bad idea.
>
> No, you have this wrong. ORMs generally use standard SQL queries to
> traverse and gather data from the DB. Then that data is placed into OO
> structures so that the application can take advanage of the bias.

Just the fact that they use SQL isn't sufficient. They have to use it as well as a person could, though an interface that is generally information-lossy enough (or at least, used in a lossy way) that that's impossible.

The most gratuitous example I can think of was some early EJB containers I played with, back when I was still thinking that ORM was something that could possibly be done well. Against a table of a few hundred rows, one could execute "delete from table". The comparable command through the ORM issued SQL to load every row as an object, then in a loop called obj.delete() which issued a single DELETE statement for that row. It was ten thousand times slower, and that's for only a couple hundred rows. Of course this example is extreme, but it's still illustrative of a general principle.

I have *often* seen four and five order of magnitude performance difference between straight SQL and ORM SQL, across a wide variety of ORMs. The very idea of ORM demands it: you have to try to push a whole set-oriented language through a functional interface.

Marshall Received on Wed Mar 05 2008 - 16:48:45 CET