Evolving persistence, SQL and ORMs to the next generation

Recently there has been a lot of discussion on the web describing the ORMs as a thing of the past, and its associated discussions that agreed and disagreed with their arguments presented to various degrees. The discussions even took a long conversations across the twitter space too.

Persistence models and application evolution

Persistence is important for any application. Over the years this has been done in various ways. While RDBMS and SQL were the most obvious choice till few years from now, recent times have also seen successful practical usage of other persistence models which include Amazon's SimpleDB, and Google's BigTable among others. These non-relational alternatives fall under the NoSQL (or “post-relational”) persistence models.

Naturally it becomes quite obvious that over the time, relational databases have proven inadequate to satisfy the growing needs of the Web2.0 applications. The advent of the new-generation non-relational databases are a proof to this. Every persistence model has a niche area to which they cater. The newer databases have has also made people to think about "mix-n-match" use of the various persistence models as people talk more and more about polyglot persistence.

The relation-object impedance mismatch

Since RDBMS has a solid theoretical foundation, and has been used across various applications, its existence for another century cannot be ruled out. Yet new advances in persistence like CouchDB, BigTable, SimpleDB, Graph databases, etc are most welcome steps in advancing the persistence mechanism.

Even with newer persistence models, a lot of the enterprise applications still use, and will continue to use relational databases. Applications that use up this data are largely represented as objects. While object model seem to be the most obvious choice for application development, the mismatch between the relational model and the object model comes as the reason for a lot of hues and cries that have given rise to ORMs. The learning curve and the pain in using these ORMs have now given rise to debates questioning the existence of ORMs in the future.

More than debating over the existence of ORMs itself, rather a deep look is needed, to the problem which the ORM is trying to solve. Why does the ORM exist? The most popular answer would be impedance mismatch. But the mismatch is pointed out between relational data representation versus the object model.

Overhauling the persistence mechanisms

Often the data storage mechanism and its interfacing API are seen as an integral part, including the RDBMS data storage and SQL. They are often seen as one, but are actually two separate components of the modern day relational databases. They were created at a time when the existence and usage of OO was questionable. Even now when they are used for a long time, it can be argued that SQL and RDBMS themselves have a mismatch in the paradigms. Now when OO has gained so much importance, it is time that the RDBMS and SQL should be re-looked from the OO perspective.

We can consider two aspects in any persistence mechanism:

1. The way data is stored (relational, key-value, hierarchical , column, JSON etc) using various data structures and storage mechanisms. Closely associated to this data storage will be the related methods of storing and fetching the stored data (algorithms used to fetch data based on persistent store itself - eg relational algebra) that could be probably exposed through function calls. The function calls will be closely associated to the data store mechanism itself.
2. Interfacing provided to interact with persistent store (SQL, NoSQL, ObjectQL, programming language API etc).

Often these two aspects are baked together (in our minds most of the time). This thinking should evolve and these two should essentially be seen as separate, and ideally pluggable. We talk about adapter pattern in programming languages, but the same concept could probably be applied to persistence mechanisms as well. The persistent storage and its storing and fetching mechanism should allow widely different interfacing provided to interact with it. DB vendors can provide few interfacing mechanism, and also allow others to write other interfacing mechanism that should be pluggable.

Interfacing will expose the persistent store in various forms - relational model, or object model or even other models used now and may come in future. Mapping of the datastore persistence model to the exposed model should reside with the interfacing mechanism used.

Concluding thoughts

Achieving this practically may not be very easy, but not impossible. Once this is achieved, ORMs will rather shed off the mapping weight and evolve as frameworks that enhance developer productivity on issues like caching, application scaling etc. Rather, ORMs will no longer be ORMs and probably a new breed of softwares will evolve that will take care of the cross-cutting concerns for an application when dealing with persistent stores.

This may look crap to some, but then that is what I wish. I am an application developer presenting my ideas on what a database itself can provide, and how applications can leverage the new capabilities. The issue needs to be looked at by db vendors and research scholars. DB vendors and db developers need to give deeper thoughts to the problems faced by application developers in their need to persist application data. How many of us use the bare databases (using only SQLs probably) without an application? The current forms of persistence may be right in their own theoretical framework, but it should evolve to fit in seamlessly with the application development space, where it is used.

And till that happens, I will have to carefully weigh my choices among NoSQL, SQL and ORMs, and muddle with the problems that have already heated up a lot of discussions in the application development space.