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 ). 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.
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.
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.