A recent article on Object-Relational Mappers and the rising of non-relational databases has spawned a lot of comments on their benefits and drawbacks.

ORMs have been given many nicknames over the years, like the Vietnam of computer science. In the opinion of the author, ORMs are dumb, as it is a fundamentally broken idea to store an object graph into a relational database.

ORMs and ODMs

Are ORMs so unuseful? It seems that JBoss’s Hibernate, the first generic ORM worth its name, was a revolution for the Java world. To the point that the PHP open source community is following up by creating Doctrine 2 as an Hibernate for PHP.

It’s no mystery that sometimes ORM are a leaky abstraction and you’ll have to write a bit of SQL from time to time in critical points, to enhance their performance. But this is true also for every NoSQL store when used in companion of an object model.

For example, consider the MongoDB Object Document Mapper project started by Jonathan Wage, one of the core Doctrine developers. It is the equivalent of Doctrine, but it uses MongoDB, a non-relational database, as the target storage for an object graph. Here you have to do a mapping anyway, only it is performed by an ODM instead of an ORM.

How to persist an object graph

The only pure solution to store an object graph for persistence purposes is to do a periodical dump of the RAM (not always viable), or to run an object-oriented database as the primary storage mechanism.

Object-oriented databases raise lots of issues, apart from the poor support by hosting services. They’re specific to a programming language, and often violate the encapsulation of the single objects. Ideally, you shouldn’t be able to access private properties of objects to make queries on them.

It seems that an object-oriented model is not so fond of being persisted anyway: it is based on graph traversal local algorithms (and the logic of where to go in the graph is distributed in the methods of the various objects). Databases in general are instead based on declarative languages such as SQL or its ORM-spiced versions like the Hibernate or Doctrine Query Language.

By the way, being able to think in objects gives many advantages to a developer, mainly easiness of test, and freedom of modeling. Every PHP framework is object-oriented nowadays, even if PHP has historically been behind other languages in the adoption of this paradigm.

At the same time, databases are good at storing data and perform bulk operations on it directly. Every ORM allows to define UPDATE or DELETE queries which act on a large data set, but do not result necessarily in the reconstitution of a large part of the object graph.

Conclusions

Thus, ORMs meet many use cases for developers that want a level of abstraction over relational data stores and to avoid writing boilerplate code for data translation. Other types of Data Mappers suitable for NoSQL databases like MongoDb are growing. Do you think we will see the success or the failure of these solutions in the near future?