Re: Object-relational impedence

On Mar 14, 2:17 pm, frebe <freb..._at_gmail.com> wrote:
> On 13 Mar, 18:40, Robert Martin <uncle..._at_objectmentor.com> wrote:
>
> > The real point of that remark was that the user of a tool is at a
> > higher level of abstraction than the tool itself. SQL is a tool. ORMs
> > are tools that use SQL to get their job done, just like compilers use
> > assembly to get their job done. In that sense ORMs live at a higher
> > level of abstraction than SQL.
>
> Lets have an example: There are many "compiler" products translating
> from a high-level language like ADA to a low-level language like C,
> instead of translating to machine code directly. What if someone wrote
> a "compiler" translating C source code to ADA source code, would that
> make C more high level than ADA? Hardly? The existance of a product
> translating from language A to language B doesn't say anything about
> the levels of A and B.

In any case, Marshall nicely described the difficulty of writing a reasonable ORM in the first place. This has more to do with the impedance mismatch than with some notion of "higher level". The RM is suited (and only suited) to representing and querying information in the form of large sets of propositions, whereas OO is suited (and only suited) to building state machines within an abstract computational machine. I would hardly call a set of propositions a state machine, and I would hardly call a state machine a set of propositions. Therefore there isn't really any overlap in the purpose of OO and RM. Not surprisingly the best approach to build a system is often a hybrid of the two. The idea to directly map a tuple (or "record") to an object reveals confusion. A tuple is a non-scalar value representing an immutable fact. An object is an identifiable state machine within a larger abstract computational machine.

The RM has a sound mathematical basis, and it's clear that the RM will stand the test of time. Any OO programmer who thinks it's reasonable to wrap RM behind an ORM doesn't understand the RM, its fundamental importance, the extent to which data can be decoupled from application and the tremendous value in doing so. Received on Fri Mar 14 2008 - 09:46:58 CET