No to SQL? Anti-database movement gains steam.SQL Databases Are An Overapplied Solution (And What To Use Instead)Hacker News thread on the topic.
Honestly, I hope the anti-database, anti-SQL movement really takes hold. On some level, I guess I should ask myself why I respond to things like this. There are several things going on here, and none of them have to do with SQL's shortcomings(there are many, but I claim most of the haters wouldn't know what was wrong with SQL if it mugged them in an alley and stole their wallet).
So lets go ahead and lay it out. This is all about Scaling.
I'm Going To Scale My Foot Up Your Ass pretty much sums up how most organizations should think about scaling. If you need to scale, and don't have VC money or a revenue stream to support it, turn the server off and walk away. Also, if you have "scaling trouble", perhaps you should first take a look at your code and stop doing whatever dozen or so stupid things you're doing. Also, try adding an index.
No why do I claim taking a look at optimization? Well, modern computers are very fast, and have lots of memory. One computer can do a whole lot. A lot more than you think.
But lets say you do need to scale. Have you considered that this "one size fits all" thing is driven by existing database management systems. Most DBMS's are either file based or server based systems that work on one computer, and require you to build replication and sharding in the application level. Yeah, that sucks pretty hard. But please explain to me where the language/relational model/SQL fit into that? It doesn't. A SQL RDBMS does not have to work like PostgreSQL, MySQL, or Oracle. It can work all kinds of ways. ACID, as an aside, is not exactly the relational model either. Now, consistency is related to the constraint checking in the relational model, but consistency in distributed(and non-distributed systems) is not the same kind of consistency as the constraint checking described in SQL. I suppose I could devote part of this article to explaining in more detail what I mean, but suffice to say that relaxing consistency(what most big scalable data stores usually sacrifice to gain scale) is perfectly in line with the relational model.
Now, specifically on to SQL. The two big things I see in the complaints are that no SQL database server easily scales to multiple computers, and SQL database servers tend to not support BLOB's very well(JSON objects are BLOB's, and if you're wanting one of those XML datastores, GTFO, because you don't have a clue...).
So, what everyone has failed to explain to me so far is why someone building one of these scalable stores can't support SQL as a query language, and add a BLOB/CLOB/JSON/crap primitive datatype?
Well, I can explain part of it. Google: Most of the people building these datastores has surely at least glanced at the papers Google, Amazon, and others have published on building systems like this(and if they haven't, shame on them, if you're going to talk about scalability and don't have the cojones to understand Paxos, you fail, GTFO).
Of course, the other problem with all of this obsession with scale, and poking fun at normalization, joins, static typing, is that it ignores why people have sought these things. Now, I'm not quite a Waterfall/Big Design Up Front kinda guy, but you see, for all this discussion of agility and flexibility in the world, most of the time we fail to realize that that's exactly what a good design gives you. Of course, many of these people are poking at relational modeling, well, unfortunately, I have bad news for you. Modeling is exactly what programming is. A program encompasses a model of reality. When that model maps reasonably well to some subset of reality, the program is useful. When it doesn't, you fail. And you can't model all of reality(first off, why would you want to? Most "role playing games" don't role play trips to the outhouse... um, but if you make a best selling game that does feature this revolutionary idea, I'm open to kickbacks...).
tl;drI'm not trying to convince anyone of anything, mostly poking fun at people who don't want to use "SQL databases" as lightweights with a narrow vision of databases(ironically).