Re: Object-relational impedence

From: Brian Selzer <>
Date: Wed, 12 Mar 2008 01:03:46 GMT
Message-ID: <SZFBj.17247$>

"Bob Badour" <> wrote in message news: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 <>
>>>>>>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
>>>>>>>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.

Mastery is evident in those who have attained it. Fortunately, most can recognize those who self-aggrandize as the charlatans, pretenders and frauds that they are. Received on Wed Mar 12 2008 - 02:03:46 CET

Original text of this message