There are many questions regarding how to store application data. Should I use NoSQL or stick with a relational database? If I choose a relational database, then should I use an object-relational mapping (ORM) tool? Although the safe answer is "it depends," another answer that's been emerging lately is to combine NoSQL, SQL, and ORM.
For better or worse, the bulk of today's business applications are forms over data. The core components of these applications are an object-oriented development language and toolset such as C# and the .NET Framework, combined with a relational data store such as SQL Server. This combination has persisted for a long time because it works—object-oriented application development lets programmers create reliable, reusable, and upgradable software. In addition, relational databases are the best tools available for efficiently storing and reporting data.
However, the combination of an object-oriented language and relational database creates a bit of cognitive dissidence for the programmer. The best way to organize data in an object isn't the best way to organize data in a database. Therefore, every application is a bit ugly because it's translating objects into relational data and vice versa.
ORM tools have grown up to address this issue. The goal of ORM is to simplify the translation process. But a very difficult balance must be achieved because simplicity often limits flexibility and performance. Those limitations don't arise until after the first version of the application has shipped and any attempt to remove the ORM tool becomes prohibitively expensive.
Achieving satisfactory performance involves circumventing the simplicity of ORM. For example, if you're writing stored procedures in a database for speed and adding a lot of extra code to make it work, then you're undermining the reason you wanted an ORM tool in the first place.
Although the NoSQL movement involves a large variety of technologies, one part of the movement addresses the SQL versus ORM debate in a simple way by storing objects as objects. The benefit of this approach is obvious: Less coding for the developer means that he can incorporate more features in less time, which results in awesome performance so that customers don't have to wait as long for a new release.
However, the downside to a NoSQL data store is that the developer is also responsible for the back-end reporting side of things. Off-the-shelf reporting tools need relational databases! All that additional coding for reporting takes away from some of the benefit that's gained from using NoSQL.
Combining NoSQL on the front end with a relational database on the back end provides the best of both worlds, and it's not that far-out of an idea. For years, large-scale applications have used two relational databases: One database is tuned for transaction speed on the front end, and the other database is tuned for reporting on the back end. Data is automatically replicated between the two.
The key to the NoSQL and SQL combination is the replication process, and that's where ORM comes into play. It provides an asynchronous, low-coding solution that updates the database from the NoSQL data store. You get the performance benefits of NoSQL and the reporting benefits of a relational database, plus the simplicity of using ORM for translation without performance concerns.
