Your program's business objects and database want to be different things

How little things change, it seems. In the mid 90's, at my first really serious programming jobs, one of the first things we did was to create our business objects and start developing "DB" classes to persist those objects to a relational database and populate them from database queries. Back in the Java 1.1 days, before the bounty of free frameworks to do that kind of thing for you, it meant writing lots of SQL code by hand, stitching together strings for SELECT statements with fields from the user's query, trying to santitize it so that funny input wouldn't break the query string, etc. This approach had lots of drawbacks: not only was it labor-intensive to get working in the first place and somewhat brittle, it was also highly resistant to needed updates in the business objects (something that's inevitable in a startup as plans change), and subclassing the business objects to add new fields made for even more fun.

And today... well, we have frameworks to do this for us, from EJB to Hibernate, but the underlying problem is the same: objects and database are based on fundamentally different concepts, and bridging the two can be a difficult pursuit. And short of abandoning one side or the other -- using an object database, or using shallow, row-like data models in your application -- it's a challenge that many of us will continue to have to deal with.

Writing in ACM Queue magazine, Craig Russell takes a look at Bridging the Object-Relational Divide, explaining the problems it addresses and why it's so frequently talked about, noting that "in modern applications, however, the amount of effort devoted to persistence can dominate the cost of a project, and using ORM tools can significantly reduce this cost."

"ORM can provide significant improvements in programmer productivity, application quality, and maintainability. One of the most important ways this is achieved is through separation of concerns: separating the behavior of the domain object model from the access of the data from the database. Using a standard API allows the choice of implementation to be a late decision, providing more time for evaluation of alternative mapping and database technologies."