Choosing the Right Database for 2018EDIT
As programming languages continue to evolve, so do the options for storing data. While SQL and RDBMs have largely dominated enterprise development for decades, the increasing demand for big data and scalability has led to the denormalization of data storage. Things like Cassandra and MongoDB have quickly gained traction in the development community as applications are constantly demanding faster performance and more data.
In this article, we address the modern day 'status quo' for choosing the right database. We also look towards the future of 2017 and how data storage will continue evolving over time.
What Database is Right for You?
There are many options when it comes to data storage. All of these options have their strengths and weaknesses and finding the right one can be daunting. It's always important to keep the end in mind as choosing comes down to a few key questions. They are:
What will you do with the data?
What you do with the data you store is critical in determining the best fit for your project. If your application is largely read only, then NoSQL may be the way to go. Non relational databases like MongoDb are great for fast lookups due to their hierarchal document structure (unlike relational models which rely heavily on strict relationships between tables).
If your application will be doing more processing (atomic reads/writes, aggregations, etc), then stick with a more normalized approach such as MySQL or Postrgres. These are great examples of relational databases that are more reliable for transactions and atomic writing than their denormalized counterparts.
How much will this data change over time?
If your data will change a lot over time then you will require a more flexible schema. NoSQL is great for ccommodating this as it doesn't rely on strict relationships with other models/tables. Everything is stored within the same document tree, making it easier to add/remove data attributes on the fly.
Sometimes you require a strict schema that won't change much over time. This makes SQL a better fit. Sure it makes for a less flexible data model, but the benefits of RDBMs can outweigh the pains of maintainability. This is why things like SQL Server and MS SQL remain popular for enterprise solutions that stress reliability and consistency with data storage.
NoSQL: The Option for Tomorrow
In answering the above questions, you start to see the trade offs between using a relational/non-relational model. While things like transactions continue to make a strong case for the SQL, NoSQL options are increasingly finding ways to compensate. ODMs like Mongoose provide better object modeling, making it easier for developers to create their own transactions and perform pre/post save operations with NoSQL. Things like MongoDb and Cassandra are also open source, creating a rich community full of libraries and extensions that address the pitfalls of denormalized data storage.
It's important to always keep the end in mind when deciding what database is right for you. While RDBM's still have their place, they are quickly being phased out by NoSQL solutions. This is largely due to the huge success seen with NoSQL and big data in more recent years. This coupled with the increasing number of open source solutions available to the NoSQL community have many DBAs thinking it's time to denormalize. After all, who doesn't want their database ready for big data in 2017?