Re: Object-relational impedence

From: Bob Badour <>
Date: Tue, 11 Mar 2008 14:10:01 -0300
Message-ID: <47d6bced$0$4064$>

topmind wrote:

> Robert Martin wrote:

>>On 2008-03-06 02:29:51 -0600, Marshall <> said:
>>>On Mar 5, 10:32 pm, Robert Martin <> wrote:
>>>>On 2008-03-05 09:48:45 -0600, Marshall <> said:
>>>>>On Mar 4, 11:05 pm, Robert Martin <> 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.
>>Wow, it's sure getting deep in here.  I can't seem to make out the
>>content for all the fuzz and snow.
>>1. ORMs generate SQL in a manner analagous to compilers generating
>>assembly.  Why is it analagous?  Because the ORMs can infer a
>>considerable amount of intent, and can therefore generate highly
>>specific SQL.  (The fact that many don't is irrelevant).  This is just
>>like compilers who infer intent from the code and generate highly
>>specific and tuned assembler.

> That is a huge stretch. SQL is *not* low-level. I will agree there
> are areas for improvement, but that's true with *any* language. What
> ORM's do is more like translating Smalltalk to Python (or visa versa)
> because Python fans don't want to deal with Smalltalk per dogma or
> personal preference.
>>2. Compilers got so good at this that they generated more efficient
>>(not better) assembler code than humans could (or would).  The compiler
>>had no care for art or readability.  So the compiler did things that no
>>human would dare.  ORMs have the same opportunity.

> The RDBMS already has capabilities to select optimum (or better)
> execution paths. If the ORM improves it even more, then good for it.
> Often, however, that is not the case.
>>So, in fact, it is not a reverse analogy.  It is a very appropriate
>>analogy.  The ORM lives at a higher level of abstraction than the SQL
>>because it has access to application intent, that the SQL does not have.

> You attribute magic qualities to ORM's that they don't deserve. ORM's
> are complex tools that require experts to use effectively and still
> are a source for a lot of headaches and performance bottlenecks. I've
> read a *lot* of gripes about ORM's on the web.
>>>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.
>>You are all caught up on object graph traversals as though they were
>>the only way to work with ORMs.  Indeed, most of us silly and sloppy OO
>>programmers understand that you don't want to walk unfetched object
>>graphs.  So we populate the necessary nodes in a set of efficient

> Why not compare master SQL programmers with master OO'ers instead of
> sub-par SQL'ers with master OO'ers?

Better yet, just listen to those of us who are both already. Received on Tue Mar 11 2008 - 18:10:01 CET

Original text of this message