RDBMS Are A Mismatch For Modern App Development

Relational databases require ORM, which extracts the data away, tearing apart the data and adding more overhead in the process.

This post is the last one in my series about “why RDBMS aren’t working” to handle today’s data challenges. The previous posts focused on the relational data model being a poor fit for today’s data, and in this post I’m going show why the relational data model is a poor fit for modern app development.

Why Are High Costs and Failed Projects The Norm?

Today, it’s a sad expectation that many IT projects will not meet deadlines and will be over budget. High costs and failed projects are the norm, and in fact, according to McKinsey & Company, half of IT projects with budgets of over $15 Million run 45 percent over budget, are 7 percent behind schedule, and deliver 56 percent less functionality than predicted. Even worse, about 17 percent of IT projects go so bad that they can threaten the very existence of the company.

Why aren’t more people asking what’s behind these dreadful statistics?

Yes, there are always issues with leadership, change management, poorly trained staff, etc. But, it’s perfectly fair to infer that since almost all of these IT project are using relational databases, there just might be a problem with the technology. From my own personal experience working on large government IT projects, I can attest to legacy databases being a huge source of pain. Whether I was trying to get data that wasn’t available or was trying to build a new application, legacy RDBMS databases were always a huge roadblock to getting anything done. Let’s look at the “why.”

Quick Overview of Modern App Development

First, how exactly are modern applications built? Here’s a bit of background…

Modern applications are built using object-oriented programming languages such as Java, JavaScript, Python, and C# to name a few. In the graph below, you can see the democratization of software development in just the past 5 years, and how JavaScript is really taking over.

When coding an application with JavaScript or any of these other programming languages, data structures are treated as “objects” that contain data and code (i.e. attributes and methods). The problem is that this way of handling data is very different from how RDBMS handle data, creating an impedance mismatch between the database and application programming.

To get around the impedance mismatch, developers use a technique called object-relational mapping (ORM), a bi-directional, active-active mapping between the objects in the application layer and the data as it is represented in the RDBMS schema. With ORM, application developers get to work with business rules and logic and generate views of the data in a way that makes the most sense from an application development perspective.

With this approach, the database viewed more simply as the place where data is persisted and where stored procedures are kept. And a wide number of ORM tools are available to help with the process, simplifying app development with RDBMS. Some examples of ORM tools include Hibernate for Java, Active Record for Ruby on Rails, for PHP, and SQLAlchemy for Python.

The Problem With ORM

Unfortunately, ORM is also seen as a poor workaround for a systemic problem with relational databases. One engineer, Ted Neward, even called out ORM in a blog post as being the “Vietnam of computer science” because it “represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.” Many other publications have continued to show how ORM does more harm than good. (See Jeff Atwood’s blog discussing Ted Neward’s thoughts, Orm Hate by Martin Fowler, ORM Is an Anti-Pattern by Laurie Voss, ORM is An Offensive Anti-Pattern by Yegor Bugayenko, and many others.)

ORM, rather than preserving the interesting aspects of the data inside an object, instead extracts the data away, tearing apart the data and adding more overhead in the process. And this happens after the data was already split up across tables through the process of normalization to begin with.

Going back to the example of a person’s medical record, just consider all of the various data that is part of the record that must be split across tables in a relational database. After “shredding” the data across tables, the data then must be reassembled to display or aggregate the data in the application layer in order to be presented to the user. This imposes lots of overhead, lots of mapping, and a custom framework or lots of joins in order to get materialized views of the business entity (i.e. a form or piece of paper).

The result of the traditional RDBMS architecture is performance loss and more opportunities for buggy code. In today’s fast-paced application development cycles, with users demanding more interactivity and responsiveness, the relational model shows its flaws. Rather than having to find workarounds for the mismatched relational model, developers are embracing new models that involve less abstraction and show higher performance.

A Solution for Modern App Development

If you’re a developer, then you’re probably like every other developer: you hate wasting TIME and EFFORT on anything. The unfortunate news is that if you’re using an RDBMS, you’re breaking your own rules… you’re taking too long to do things that don’t add value.

We think that NoSQL, and specifically MarkLogic, offers a sound alternative to the challenges with RDBMS. With a document database, developers get to leverage a more flexible data model that is a better match for modern application development because it avoids the impedance mismatch problem.

The document model allows developers to maintain the integrity of data throughout every tier of an application stack. For example, developers can have JSON and JavaScript through every tier, as shown in the image below. This is a more agile approach, and is a good fit for the growing amount of JavaScript used in developing modern web applications.

That wasn’t the focus of these posts, but if you’re interested in learning more, watch this talk by MarkLogic’s Director of Product Management, Justin Makeig, titled Full-stack JavaScript Development.

This is the final blog in this series about why relational databases are not designed to handle today’s data. If you’re interested in getting more info right now, you can download the white paper, Beyond Relational that covers this topic in depth.

All posts in this series:

1. RDBMS Are Not Designed To Handle Change
2. RDBMS Are Not Designed for Heterogeneous Data
3. RDBMS Are Not Designed For Scale
4. RDBMS Are Not Designed for Mixed Workloads
5. RDBMS Are A Mismatch for Modern App Development