The NoSQL Movement

The NoSQL movement is a hot topic in the development world right now. If you’re not familiar with NoSQL, check out http://en.wikipedia.org/wiki/NoSQL and http://nosql-database.org/. NoSQL is often a misleading term and doesn’t refer to just one type of database technology as SQL does (think relational database management systems such as Microsoft SQL Server, Oracle, MySQL, and SQLite. NoSQL can refer to any variety of non-relational databases such as column store databases, document databases, key/value store databases, graph databases, and many others.

As developers and DBAs, the use of relational databases and normalized data has its roots in the hardware industry. 30+ years ago when Oracle released their first commercially available relational database, there were greater hardware constraints than there were today. The biggest constraints were storage  and memory. As a result, fully normalizing your data to minimize the space needed for storage was incredible important.

Fast forward to today – the hardware industry has changed (just a little Smile). I can spin up a multi-terabyte globally-redundant hard disk in Azure in a few minutes, and only pay for the data I’m actually using (and at unbelievably low rates).

So, what has changed in the development community. quite a bit, but relational databases are still the de-facto standard for data storage. Why is this? Perhaps it’s familiarity, fear of change, fear of job security.

But it doesn’t make sense.

We’re taught to us the right tools for the right jobs. But most people aren’t even considering different database technologies and shoe-horning their data and domain models into relational databases. Don’t get me wrong – RDBMS still have their place, but let’s consider the alternatives. If you need to store a complex web of relationships between data points, you can consider graph databases. What about semi-structured data with a variable schema? Sounds like a great case for a document database.

What Can You Do?

There’s two things you should be doing right now.

One. In addition to learning the next 15 JavaScript frameworks that were released last week, take an existing project and experiment in persisting your data in a different format. If you’re using a Repository pattern, swapping out your data persistence layer can be a fun exercise (yes, I just said refactoring your data persistence layer could be fun).

Two. The next time you start a project, take an extra minute to consider whether an RDBMS is the right tool. If you’re unsure ask the community – there’s no shortage of advice.

Mike Branstein

Mike Branstein

Developer and leader. Passionate about systems architecture, domain driven design, application lifecycle management, and technology. Brosteins

This article is by Mike Branstein from brosteins.com.