ON O/R MAPPING

From: Tom Werges

Date: 21 Oct 2005

Recently I got into a discussion with my colleagues in which I claimed that the very idea of O/R mapping was a mistake. My argument was as follows. O/R mapping translates data from the relational model to a model in which we navigate data by following references. But following references is not superior to just using the relational model—in fact it's worse. So why have we gone to so much trouble translating data into a model which is worse. We've accomplished nothing, at great cost. Why not just skip mapping altogether and issue queries directly. That way, we'd get the same features (in fact, more!) but without the labor of writing all those mapping files which ultimately accomplish nothing.

However I did claim that O/R mapping offers exactly one advantage: it allows the programmer to access schema objects as first-class objects of the host language. More specifically, O/R mapping allows the programmer to navigate data, perform assignments, pass around data as parameters, etc, using the operators and types of the host language.

But I claimed that a much better way exists of accomplishing the same thing. Instead of mapping, we could integrate the relational model into the host language. That could be accomplished by adding the relational operators to the host language, and by integrating relations as types in the host language. By doing so, the sole benefit of O/R mapping could be achieved (schema objects as first-class objects), but without all the O/R crap: no more XML mapping files, DAO layer classes, mapped classes, navigating references, etc.

Aside: Bear in mind that the amount of crap imposed by O/R mapping should not be underestimated. O/R mapping requires an XML mapping file, a CRUD class, and a mapped class, for each relvar. The amount of human labor wasted worldwide on generating this stuff is staggering.

The idea of integrating the relational model into a host language occurred to me while reading something about the now-forgotten language, Pascal/R, which was an attempt at precisely that. I noticed that Ted Codd had some positive remarks about Pascal/R, so I decided to look into it by searching on the web. What I found surprised me: apparently there was a whole group of database-integrated languages, like Pascal/R, Modula/R, DBPL, and others. But they seem to have disappeared. Not one of those languages went anywhere. They never took off, and they've had no influence.

So my question is this. Whatever happened to the database-integrated languages? Is there some reason they've had no influence? Was it a bad idea? Because it seems like a vastly better idea (to me) than O/R mapping.

In fact, I'm somewhat tempted to extend the Java language to include relations as types (Java/R?). I could write a small parser and compiler to compile Java/R code into regular Java code. But I don't wish to proceed if I'm unaware of something wrong with the very idea of database-integrated languages. Do you think it would be a bad idea to extend the Java language in that way?

From: Fabian Pascal

I will let Hugh and Chris state their positions. I do know, however, that Chris thinks that the only thing that OO ads to RM is type inheritance, and that is orthogonal to the data model. For example, Hugh and Chris have proposed a TI model consistent with RM in their THIRD MANIFESTO (TTM).

My own position is that object-orientation is a programming concept, period. There is really no data model object equivalent.

Hugh Darwen Responds: Werges's idea seems very much the kind of thing that TTM is promoting. Tutorial D, though nowhere near industry-strength as an application development language, is a complete programming language with integrated relational support. Is Werges aware of what TTM is about? (I have to say that I don't really know what is referring to, specifically, with "O/R mapping".)

I don't know exactly why Pascal/R and the rest never took off. I strongly suspect antipathy from the major vendors, none of whom has ever shown any real enthusiasm for the relational model, the scene for which was ruined in any case by what Larry Ellison did in 1979.

Ed. Note: I and David McGoveran are not convinced that a unified data and programming language is the best idea. The sub-language concept is not identical to such an integrated language and, in fact, Codd was distinctly for the former and against the latter. His non-theoretical grounds for his position notwithstanding—he was not a programming/language expert, and did not want to get into the politics of standard programming languages—we prefer to adhere to it.

Posted 1/6/06