Re: Object-relational impedence

topmind wrote:

>
> Robert Martin wrote:
>

>>On 2008-03-06 02:29:51 -0600, Marshall <marshall.spight_at_gmail.com> said:
>>
>>
>>>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.
>>
>>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.

>>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.

>>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.

>>>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
>>querries.

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