An article carrying quite a few strong statements. Some I do agree with, some I don’t
New waves of application development technology are often incompatible with old ways of thinking. Typically, when a brave new world opens to programmers, a healthy portion of them will cast aside the old ways in favor of the new. But the NoSQL movement is not about throwing out your SQL databases to be replaced by key-value stores. NoSQL, ironically, has nothing to do with avoiding SQL, and everything to do with the judicious use of relational databases.
Take for example:
He said (nb Mike Gualtieri, senior analyst Forrester Research) that saving actual customer purchasing information is better suited to a relational database, while storing more ephemeral information, such as customer product ratings and comments, is more appropriate for a NoSQL database.
Saying that NoSQL is fit for “ephemeral information” is a mistake: put your “cheap” data into NoSQL and your “important” data into relational databases. You don’t use a programming language for a product that is not so important and a different language for an important one. You always take into consideration a lot of aspects before making that decision. The same applies to choosing the storage backend.
Ellis (nb Jonathan Ellis, Cassandra lead and founder of Riptano) said that the developers at Digg invented a rule of thumb for deciding whether or not an environment necessitates a NoSQL database like Cassandra: “If you’re layering memcached on top of MySQL, you’re inventing an ad hoc NoSQL database by doing that,” said Ellis.
Well, that pretty much sounds like: “if you are using a dict/hash/map then you are inventing an ad hoc NoSQL database”. Personally I think that using a caching mechanism that is accessible through simple get/set operations just means that 1) memory access offers higher speed than anything else, 2) most of the time we like accessing our data in different ways
All in all, a good read built around quotes of different people involved or looking at the NoSQL market.