The tone of the current debate reflects poorly on everyone involved.
I like the Durable Clojure hack that someone wrote, because it basically adds disk-backed durability to clojures ref types (which already have atomicity, consistency and isolation). Having ACID guarantees on built-in data structures reduces the need for databases for a lot of use cases and would be a lot nicer to work with than having to deal with an external database.
http://webcache.googleusercontent.com/search?q=cache:http://...
I wish we could have found a way to make it work within our SQL database but none of the solutions that I could find felt right. Schema-less data and complex queries (Group Bys, Distinct, etc) just don't seem to mix well with most systems. I'd love to know if others have any experience in this area.
I'll be extremely delighted when the discussion starts revolving around how well a solution fits a specific problem as opposed to declaring one or the other solution inferior or superior. A single grading scale is not what a real engineer uses.
For the record we use a "NoSQL" technology called flat files. Because our challenge is making sure the right workers have the right data in memory, not on disk.
NoSQL for me is not about scaling, it is about having a different data and query model that means creating new sorts of applications easier than with plain old SQL.
That I can build a graph database or something with xSQL is not really relevant. I can write webapps in C, but I made a conscious decision not to, I also try to select the best datastore for the job.
Making desing choices is OK. The authors admits that relational databases have different design goals and thus comaring them directly is necessarily comparing apples to oranges.
What is true and wise is that non-relational databases have been around for much less time, have less theoretical background, the development teams and DBAs are less experienced with them, etc.
