Re: Object-relational impedence

Robert Martin wrote:
> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spight_at_gmail.com> said:
>
> > 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.
>
> Yeah, assembly language programmers used to say the same thing about
> compilers. Then the compilers started writing more efficient code than
> the assembly language programmers could...
>
> In any case, good ORMs allow you to tune the SQL, so you *can* use it
> as well as a person could.
>
> > 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.
>
> It is illustrative of a programmer who either doesn't know his tool or
> didn't select a reasonable tool.
> >
> > 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.
>
> Bah. You don't *have* to do any such thing. I won't argue that there
> aren't programmers and teams who use their tools poorly.

The industry is full of horror stories with regard to ORM mappers. They are either a pain in the butt, or expensive to find and hire good ORM experts for. It is a waste of resources to translate back and forth between two fairly high-level paradigms. Embrace the RDB and don't use heavy OOP for domain nouns, and you have less headaches.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Thu Mar 06 2008 - 21:54:27 CET