A Non-Reason for Using ORM

by Krishna on August 1, 2009

There are many good reasons for choosing an ORM tool instead of using stored procedures. But one reason has always struck me as rather silly. That is choosing an ORM so that you can easily switch databases in the future. I am not disputing that using an ORM enables you more in changing databases, but I am questioning why you would want to base your project on such an assumption.

There are several problems with the idea that you would want to change databases in the future. One is that in a non-trivial application, your interaction with the database is not limited to running SQL queries against it. Most mainstream database servers have several features that enable you to gain better performance and scale your application better. And you would be well advised to use such performance tuning.

If you decide to switch to another database server, you will have to do similar activities in the new server. You would have to relearn how to do it in the new server, or hire resources who are knowledgeable in it. There is also the possibility that some data migration efforts may be required, even though tools do exist. It is not as simple as you may think and is more a distraction than a benefit to the project.

In terms of price and scalability, most database vendors also offer you an easy path upwards. You can run the lowest version on your desktop and it probably costs $0. And there would be a high-end version that scales to multiple machines and costs thousands of dollars. So the need to rewrite the software for another database server is reduced.

Now, I have seen instances where a rewrite from Oracle to mySQL (for cost reasons) or from Access to SQL Server (for scalability) or from some dead database vendor’s database to a database in the present market has been done. But these were projects where there was no ORM to begin with. If somebody started a project in recent times and then had to change their database server, I wonder what thinking they put into selecting the database in the first place.

Just as you would not choose your programming technology in a casual manner, it is important to put sufficient effort in choosing the right database server. Being cavalier about it and assuming you can easily shift database servers (and would want to) in the future is not the right way to go.

{ 1 comment }

Gergely Orosz August 3, 2009 at 7:14 am

I don’t think the real point of ORM is in the future changing of databases. By designing your application with the ability to change databases (even though you would never intend to) you give your application a much more logical structure than you would before grouping functions related closely to the database in a separate layer. I think this logical hierarchy is the thing that is really valuable.

Here’s my example. I’m working on an open source enterprise CMS at the moment, Sense/Net. It’s designed to have the ability to run on several database implementations: http://wiki.sensenet.hu/index.php?title=SenseNet_Structure However there is no other support than MSSQL implemented up to date. But over the time this segmentation has proved to be very valuable when it came to develop new features and had to decide wether they belonged to the database abstraction layer (Storage layer in our case) or somewhere higher in the hieratchy.

The only place I don’t use ORM at all is at tiny projects.

Comments on this entry are closed.

Previous post:

Next post: