NoSQL Is Technologically Inferior To SQL

What a disappointing piece of writing. Having worked with BigTable for several years at my previous gig I find the whole premise of NoSQL hilarious. BigTable really is a very specific solution to a very specific problem, creating a datastore that can feed massive mapreduces efficiently. Basically you have a design problem that nobody else is solving and you have the monetary resources and knowledge to solve it yourself.

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.

I would like to have the term NoSQL come to mean 'manipulate data as you naturally would in your language of choice, irrespective of the persistent storage system.'

The tone of the current debate reflects poorly on everyone involved.

The site must be using NoSQL, since it is down for me right now. I wish it would load, the article sounds interesting.

Just says that you can emulate any NoSQL database with a SQL one, using multi-master systems etc. And that NoSQL 'wants' to use SQL.

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.

Our company uses a mix of both. The author mentions that one of the perceived benefits is the "Flexibility of schema definition". We actually ended up needing a NoSQL database for exactly that. We have one part of our system that needed to store schema-less data in a way that still let us query it using the custom data fields.

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 wouldn't say it's technologically inferiot. I'd say it's less mature.

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.