Re: Object-relational impedence

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.

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

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

>
> > 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.
>
> Since the programmer writes the object graph, he knows how to ensure
> that the best SQL gets written... One day, the ORM will likely infer
> this from the structure of the object graph and (like a jitter) from
> the way the application executes.

MindReader 2.0

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

-T- Received on Tue Mar 11 2008 - 16:56:11 CET