Re: Object-relational impedence
Date: Fri, 14 Mar 2008 08:55:55 -0700 (PDT)
On Mar 14, 8:16 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
> > On 14 Mar, 10:43, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> >> On Thu, 13 Mar 2008 22:17:40 -0700 (PDT), frebe 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.
> >> Right. What does it, is the difficulty of designing such a compiler.
> >> Clearly within the set of Turing-complete languages you could translate
> >> from whatever language to any other. But, while translation from Ada to C
> >> is considerably difficult (mainly because C is ill-defined), a good
> >> translation from C to Ada is almost impossible.
> > That's why the OO camp has such problems with making a good ORM. If
> > SQL would have been low-level, compared to the network model, the task
> > would have been much easier.
> Not necessarily. Certain architectures are difficult to translate into, for
> vector processors. It is related to the presumption of computational
> equivalence. A difficulty or impossibility to translate can come from
> weakness of a given language. SQL is pretty weak.
> Clearly when SQL is used as a intermediate language for an ORM, then to
> have it lower level and more imperative than it is would be an advantage.
> But I agree that ORM is wasting time. In my why other architectures are
> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
> a concept.
One of the problems in translation is that OO usually makes a big distinction between an individual object and a collection of objects, whereas in RDBMS there is no real difference: going from 1 to a million is seamless (outside of performance issues). In OO, the collection is usually a different object/class than the items in the collection. (This is a manifestation of the set-oriented thinking versus navigational structures of OO.) Nobody has figured out how to use encapsulation to hide the difference.
Cursor-like techniques can be applied, but that just makes OO look like a half-finished (navigational) database because objects then must start following global collection-oriented rules, losing the self- -noun feel that makes OO feel like OO.
I don't think anyone can solve the impedance mismatch without turning one into the other. Each allows/requires different areas of freedoms and restrictions. If you plug up one, you have to open another to compensate, and visa versa.
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
-T- Received on Fri Mar 14 2008 - 16:55:55 CET