All the people that show up to NoSQL articles and say, "you should always use SQL" are the ones that happened to use relational databases for the right tasks.
I wish there was a delay between when screws were invented and when screwdrivers were invented so that we could have seen the NoHammer movement. Of course you shouldn't screw in screws with a hammer. But hammers handle nails pretty well.
How about "if MySQL doesn't do it, then much more expensive databases might do it poorly after a whole bunch of effort"
Perfect.
Or even added: , but what we are really talking about is half finished databases with limited capabilities that happen to suite a specific need. The reality is SQL is in no way a limitation on a database design, however by lowering the bar you can build a useful prototype which at some point might become a database. And then gone on to describe an actual problem with an interesting solution.
Fantastic.
You´d be wrong...
This essay is long and disorganized. To spare those who would other wise have to suffer through it the trouble: It's basically a defense of the the term 'NoSQL' as a description of the collective of hash-key stores, documents dbs, etc that have been gaining popularity of late. His claim: 'NoSQL' represents some kind of escape from the oppressiveness of SQL and is a radical break with accepted DB technologies.
It's posts like this that bother me most about about the NoSQL crowd. Hash-key stores, document DBs, and other equally innovative things have been in existence and in use for decades. Periodically, people try to promote these technologies as replacements for RDBMs and each time, we learn that while they have their place, so do RDBMs. NoSQL is not revolutionary; it's a practical extension of pre-existent technologies that solves a set of problems that current RDBMs don't address, while RDBMs still solve the set of problems that they were meant to address.
All this revolution nonsense is just that, and that's why people are so worked up on both sides.
These labels bundle CouchDB into the same category as heavier-than-relational OO databases.
A much better grouping label would be 'map cloud'.
As soon as it turns into "we're using Project Voldemort, can you figure out how to hook a reporting tool up to it tomorrow?", you find a lot less consensus.
I should add that HBase and Cassandra support integration with Hadoop and Hive/Pig, but all the usual warnings about the load of reporting jobs against a serving database apply-- one solution (with Cassandra) that I've heard is to place a the "reporting" machines on a different network e.g., on a different vlan in your own datacenter or in a different EC2 availability zone.
Now SQL has ease of use, a myriad of tools such as ActiveRecord, or Hibernate, an ANSI specification. All of which allow developers to quickly pump out a site that will handle the needs of 98% of the businesses out there.
There is no need for a small time web store to be using a Hadoop Cluster, just like we wouldn't expect Google to be running on a MySQL backend.
As someone who has worked in both sides of the industry, I can definitely say that trying to integrate a NoSQL solution with a standard 3 Tier type website would increase the cost of development 10 fold. Sure, you can get it with no license fee, but you end up paying for it elsewhere.
Basically it boils down to NoSQL != NoPricetag
P.S> I recently wasted a week of my life trying to get HBase up and working on a small cluster with the data from our Vertica solution. I ended up using InfoBright and got it up and data loaded in a few hours. I am still open to the NoSQL idea for our specific business, but why can't it be just as easy?
