First and foremost, see that I am saying "#knowsql, not just #nosql". I am not saying "#knowsql, not #nosql." Second, I am not putting #hadoop in the #nosql category -- it is not a #nosql engine, it is "do what you want with it" engine. Pig's and Hive's add data models to it, but that is a separate topic.
10. SQL is the language that talks about "select project joins" but uses the word SELECT for project!
9. SQL databases do not ignore ACID properties unlike most of #nosql databases. Have you tried to reason about "eventual" consistency a la Cassandra?
8. You have choice of implementation, not lock-ins to one technology, one implementation.
7. Your system does what you want and you do not have to tell how you want it done (Declarative vs. Procedural?)
6. Billions of R&D dollars are being spent on improving SQL databases per year.
5. 95% of the hottest database "system technologies" (like hardware acceleration, GPU exploitation, multi-core exploitation) focus on SQL, not #nosql. {Obvious Anant perspective, can be questioned as to what I mean by "hottest".} So SQL will get leaps and bounds of performance improvement over the next few years.
4. 95% of cloud projects are on SQL, not #nosql. {Anant perspective, but verifiable. Working with @sogrady to see what numbers we can come up with.}
3. SQL databases can now handle RDF, XML, key value stores without sacrificing ACID.
2. Most real data persistence needs are sub ~200 TB, easily a sweet spot for SQL databases.
1. Every #nosql in the end either already has, or will, put up an SQL-like layer. Look no further than GQL (google).
The other thing that might be pointed out is that database vendors are increasinly adding support for advanced in database analytics,
being able to take the results of your SQL query and feed it into a clustering algorithm developed in the R lanaguage, with out ever having to leave the databse.
Posted by: Erich Hochmuth | July 15, 2011 at 05:27 AM