SQL vs. NoSQL May 09, 2011
Relational databases have maintained their rule over information systems. But over the past decade a competitor has risen, challenging some philosophical notions people have long since held onto. These NoSQL competitors have an innovative outlook for clustering, cloud computing, and large stores of information.
Could this be the end of SQL as we know it? I think not. To provide clarity on this issue, Let's take a quick look at why people have been pushing for NoSQL.

With the rise of the internet, and the further development of the informational age, large amounts of information need to be stored and accessed very quickly. Relational databases have their limitations here, simply because the SQL engine is designed to make sure everything is linked together correctly.
For example, imagine a data mining algorithm that collects millions of mouse clicks from users around the world. Is it more important for the data to be recorded correctly, or to be relationally sound? Obviously the data needs to be stored correctly. It is disastrous for a data mining application to be unable to store any actual data!
The misconception comes when people view NoSQL as a replacement for SQL. It isn't. NoSQL is a philisophical adaption to a unique set of problems that relational databases are not fit to solve. But SQL still has its benefits. I don't trust the security aspects of my applications to Cassandra; I code it into MySQL.
Here is the point: it is not an "either-or" debate, but a "both-and" tension. Depending on your application, you may need to employ both types of database structures. That's okay. There are multiple programming languages for reason. The goal is not to pick "the one", but to understand the pros and cons of each, and leverage what you need to create the best product.
