The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge.
I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.
I disagree. Lots of applications only require dumb bit buckets. There is no real sophistication or structure to the data. Anything more is over engineering for a large majority of products which data storage is not particularly useful or meaningful.
I worked on a system a couple of years ago where we ran calculations nightly and then we write the results of this calculation to a row in a table for caching purposes. This row was then fetched by another job to generate a PDF. We used SQL for this because Reporting Services could build a pdf from a row in a table.
It's not a good solution. This type of data doesn't need to be searchable. It's using a database server as a caching mechanism. That seems wrong. Seems like memcached, mongo, couch, or anything else would have been better.
Heck, people have been using memcached for a long time, and yet all of a sudden people don't see a use for NoSQL setups?
Are we sure we're not just doing the same old "Defend what you know" dance?
I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.