Object Relational Mapping

I saw a demonstration last night of object relational mapping (ORM) tools. The idea behind them is that object oriented programming (OOP) and relational databases (RDBMS) model the world in two totally different ways. OOP tries to express everything in terms of behavior and properties, whereas RDBMS focus on efficient data storage, and do not support the kind of behavior that OOP provides. You can program in a RDBMS (with stored procedures, or functions) and you can store data in objects. Both approaches have their pros and cons. At the moment, OOP is the dominant way to write software (Java and .NET languages sit on top of huge libraries of objects) and RDBMS is the dominant way to store data (Oracle, SQL Server, etc.).

Programmers being programmers, clever people have put together some ways to allow the OOP people to have their cake and eat it too. They can program against objects, and then have a whole bunch of backend code handle the dirty details of getting data out of and back into the RDBMS. Of course, there is no such thing as a free lunch, so there is an overhead associated with this.

I could see how the approach would allow you to cleanly separate out your business objects (e.g., customers, orders, etc.) from the nitty gritty of the data storage (e.g., the exact SQL statements to retrieve or insert data into a database) and insulate your business logic from future changes in data storage technology. Some frameworks go one step further and define a domain specific language (DSL) to allow you to express your business problem solution in something that resembles normal English (COBOL-esque?).

In a large number of cases, there is significant investment in existing code, written in such a way that you cannot simply switch approaches on a whim. When something like ORM comes along there needs to be a cost-benefit analysis (CBA) of whether or not it is worth it to make the switch. The software developers hear this and hear "blah blah blah", knowing that the suits just want to kill their fun. If they are serious enough about their fun they will go to a startup company that is doing greenfield development where they can indulge their latest cutting edge ideas.

Ironically, in three to five years something else will come along, and if they have totally bought into whatever the new thing NOW is (for example, ORM) they will decry any attempt to move away from it, having written tens of thousands of lines of code using it.

I guess it is the fate of all software development to eventually become obsolete and fall by the wayside, but in some niches you can survive for a very long time until that CBA finally tips the scales over, and the maintenance payments to whichever vendor or ability to find programming talent to keep your AS400 / COBOL / PowerBuilder payroll system alive become too difficult.

I suspect I will run a small pilot project using an ORM framework, to see what benefit there is, and to show that we are "keeping up", but for now I think it is going to be one of those things that simply does not pay off enough to warrant a wholesale shift.