NoSQL vs. SQL: SQL is the new NoNoSQL

The great NoSQL vs. SQL battle ranking

Description NoSQL SQL Score
Is it an ISO / IEC standard No Yes [1] 0:1
Is it any standard at all No Yes 0:1
Is it even a well-defined concept No [2] Yes 0:1
Is it based upon a rock-solid theory No Yes [3] 0:1
Is it mature No Yes [4] 0:1
Is it well understood No [5] Yes 0:1
Is it something new No [6] No 0:0
Will it still be there in 10 years Maybe Yes [7] 0:1
Can it handle relational data models Maybe [8] Yes 0:1
Can it handle hierarchical data models Maybe Yes [9] 1:1
Can it handle unstructured data models Maybe Yes [10] 1:1
Can it handle graph data Maybe [11] Maybe 1:0
Can it scale up Yes Yes 1:1
Can it scale out Maybe [12] Maybe 1:1
Total score NoSQL SQL 5:12

Clarifications about the above

  1. The ANSI / ISO / IEC SQL standard has been maintained for almost 30 years in various dialects: SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011. New features are added all the time and the most popular vendors implement them.
  2. NoSQL as a term has been coined by Carlo Strozzi's when he created a "NoSQL" relational database. Ever since, proprietary notions of databases have popped up with a common marketing notion of not offering SQL as a querying language, and even that isn't true as some databases use a SQLesque language but are not relational.
  3. Relational algebra was created in the 70s by E.F. Codd to solve the mess software engineers and computer scientists faced in a time when every company and their dog implemented home-grown databases. Codd was visionary and solved things at a greater level. SQL is a good implementation of a mixture of relational algebra and relational calculus, give or take one or two features or notions. Being built upon such a rock-solid mathematical model, SQL is very sound.
  4. The best commercial databases (and maybe PostgreSQL) are incredibly mature and capable of serving thousands of very complex requests per second. It is very hard to bring down a well-maintained and well-tuned Oracle database. It is also very easy to find skilled DBA personnel for your popular commercial RDBMS.
  5. If ever you have a SQL storage, performance, or any other problem, it is very easy to get help. Because these kinds of problems aren't new. Generations of developers have had them before you. This is not the case with your vendor-specific NoSQL database. You will always have to turn to the vendor and you cannot compare problems from one vendor with those from another one, because there is no common underlying, rock-solid relational model.
  6. Even if the term NoSQL is rather new, the notion of writing databases for a very specific problem domain is not. In pre-Codd, pre-relational, pre-SQL times, there were hundreds of different types of databases. Even in more recent times, we've had document stores (XML, operating system file systems), key-value stores (come on. Any hash map is a KV store). Some would argue that even a CSV file is a NoSQL database.
  7. It's not easy to switch RDBMS vendors, but if you have to, you can. You cannot do that with NoSQL stores. They're all completely different. By choosing NoSQL, you're choosing the biggest vendor-lockin of your career.
  8. Have you chosen a rarely used, vendor-specific data store just to emulate the relational data model? I hope not. But why are there an increasing number of blog posts and Stack Overflow questions about how to JOIN in MongoDB? Are you using the right database?? Don't JOIN if you're using MongoDB. Don't use MongoDB if you need to JOIN.
  9. Many RDBMS can deal with hierarchical data through SQL:1999 recursive common table expressions. Oracle and CUBRID ship with the proprietary CONNECT BY clause. Do you really need to switch your data store if you have 1-2 hierarchical relationships in your database?
  10. Yes, you can put unstructured data in a BLOB or CLOB. As simple as that.
  11. Granted, the relational model is quite bad at modelling graphs.
  12. Yes. Some NoSQL databases were designed to scale out massively. But 1) they pay for it (see CAP theorem) and 2) you're not Twitter or Facebook. Do you really need this kind of scaling? Or do you maybe have a simple performance problem related to bad indexing?. Do note that you can scale out significantly using sharding with RDBMS as well.

And the winner is: SQL, the new NoNoSQL

A History of Databases in No-tation

(according to Mark Madsen, photo by Edd Dumbill, seen at the O'Reilly Strata Conference):

comments powered by Disqus

SQL is the best language to query databases

jOOQ is the best way to write SQL in Java.

jOOQ generates Java code from your database and lets you build typesafe SQL queries through its fluent API / query DSL.

jOOQ lets you get back in control of your SQL.

SQL is the best language to query databases. jOOQ is the best way to write SQL in Java.