RDBMS Are A Mismatch For Modern App Development
Posted by Matt Allen on 20 November 2015 08:00 AM |
|
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. Quick Overview of Modern App DevelopmentFirst, 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 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 ORMUnfortunately, 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.” See Jeff Atwood’s blog, ORM is the Vietnam of Computer Science, and Martin Fowler’s blog, Orm Hate 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 DevelopmentIf you’re a developer, then you’re probably like every other developer: you hate wasting TIME and EFFORT on anything. 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. We also have a great book, Enterprise NoSQL for Dummies, if you’re interested in learning more about NoSQL databases in general. 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:
RDBMS Are A Mismatch For Modern App Development from MarkLogic. | |