The Dangers of Object-Relational Transparency

One best qualities of a good abstraction layer is that it doesn't require you to think about that which has been abstracted. When writing C and Java, one doesn't have to know, or care, about the state of the machine's registers.

On the other hand, this can be a danger, particularly when the abstraction has leaks, even small ones. I was reminded of this the other day when, having assembled a design for a problem I was facing in the data model, I was having trouble finding a way to translate it to the object model.

After discussing several approaches with two of my colleagues, I eventually realized that the biggest stumbling block was my desire to translate the data model design to the object model, encouraged by the use of Hibernate, which does a great job of mapping like objects and tables.

In this instance, the best solution to my problem was to use a different object design than I was using in the database. As soon as I framed it this way, my challenges dropped away and I quickly found a suitable design for the object model.

This problem occurs at least in part because we are unable to accept that the database is an abstracted layer. There are some good reasons for this:

• database-application interaction remains one of the primary architecture elements that has a significant impact on scale and performance of almost any web application.
• database-level integration for two or more applications and/or tools is inexpensive and pervasive.

There is, however, a price -- you need to consider the design of each, and sometimes the best design in one is not the best design for another. I needed a reminder of this the other day. Do you?