Re: Object-relational impedence
Date: Thu, 6 Mar 2008 00:29:51 -0800 (PST)
On Mar 5, 10:32 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi..._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...
I give you high marks for rhetoric here. Excellently argued! You take the opposing side and compare them to assembly, and compare yourself with compiled languages. That the situation is most closely analogous to exactly the reverse is only relevant if one is interested in a deep understanding doesn't detract at all from the rhetorical effectiveness.
As an actual engineering argument, though, this fails. Because it doesn't address the information-loss point I made. No code generator can write optimal code if it's missing information necessary to determine what is optimal. Object-graph traversal in ORMs is *necessarily* more expensive than straightforward SQL. In part exactly because it is *necessarily* missing the information present in the head of the programmer who writes instead a single SQL statement, information that is then embodied in that statement.
> 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 agree that the ultimate problem here is the programmer not selecting a reasonable tool. In particular, a programmer who selects an ORM has not selected 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.
ORMs are a breeding ground for antipatterns. OO code written in the style you advocate (Employee.get("bob")) is a performance disaster first, and benefit-free busy work last.
Marshall Received on Thu Mar 06 2008 - 09:29:51 CET