That's one of the reasons why the whole 'NoSQL' thing is silly. No SQL picks the wrong battle. SQL just fine as a compact language for expressing certain things.
I don't think it's silly at all. If you give something a name, people can start talking and reasoning about it. The same thing happened with AJAX - the name was dumb (it doesn't have to be Asynchronous, it doesn't have to use XML and it doesn't even need to use JavaScript) but the term kicked off something of a revolution in web development just by giving people the vocabulary to discuss it. It feels to me like the term NoSQL is having the same kind of effect - for the first time in years, developers are talking and thinking critically about their choice of data persistence layer.
The trade off you make to get the performance attributes, scalability, schemaless flexibility, etc from a NoSQL storage solution is that you end up in a different query situation. Things like joins aren't as easy - but at the same time the cost of doing what in RDBMS land you'd consider "Denormalizing" (potentially duplicating data as needed) is much, much lower.
As for translation, the Mongo guys have produced a JDBC driver (for those of you stuck in java land, but at the least it's a code model for "Howto"; disclaimer: I haven't had a chance to use it yet) that supports some automatic translation of SQL statements to Mongo queries - http://github.com/erh/mongo-jdbc
They're both nice. Because the data modelling paradigms are so different, I don't see much point in trying to shoehorn SQL into MongoDB.
Consider the case where you're modelling blog posts with zero or more tags. In a relational database you'd typically have a posts table, a tags table, and a posts_tags join table. In MongoDB you'd have a posts collection with an indexed array key for the tags.
Searching for all the posts with the tag foo is just: db.posts.find({tags: 'foo'}).
Looks pretty nice to me. Why would I want to use a relational query language for a document-oriented database?
In fairness, this chart plays directly to SQL's strengths by simply implementing built-in functions of SQL like SUM using MongoDB MapReduce. Clearly the MongoDB version will be more verbose in this case.
Because MapReduce is much more general than these few built-in functions, one could probably pick a task that would make the SQL version look horrendous compared to the MongoDB approach.
Agreed. And it certainly doesn't address the other trade-offs that make the whole SQL/Not-only-SQL discussion fascinating. I just couldn't resist referencing this: http://browsertoolkit.com/fault-tolerance.png
17 comments
[ 3.1 ms ] story [ 35.2 ms ] threadThe trade off you make to get the performance attributes, scalability, schemaless flexibility, etc from a NoSQL storage solution is that you end up in a different query situation. Things like joins aren't as easy - but at the same time the cost of doing what in RDBMS land you'd consider "Denormalizing" (potentially duplicating data as needed) is much, much lower.
As for translation, the Mongo guys have produced a JDBC driver (for those of you stuck in java land, but at the least it's a code model for "Howto"; disclaimer: I haven't had a chance to use it yet) that supports some automatic translation of SQL statements to Mongo queries - http://github.com/erh/mongo-jdbc
http://rickosborne.org/blog/index.php/2010/02/19/yes-virgini...
I've submitted it here:
http://news.ycombinator.com/item?id=1166876
Consider the case where you're modelling blog posts with zero or more tags. In a relational database you'd typically have a posts table, a tags table, and a posts_tags join table. In MongoDB you'd have a posts collection with an indexed array key for the tags.
Searching for all the posts with the tag foo is just: db.posts.find({tags: 'foo'}).
Looks pretty nice to me. Why would I want to use a relational query language for a document-oriented database?
Because MapReduce is much more general than these few built-in functions, one could probably pick a task that would make the SQL version look horrendous compared to the MongoDB approach.
Often you'd layer a more expressive declarative language on top of that, which is what drivers like MongoMapper or Mongoid provide.
Even within the JavaScript interpreter you can be writing declaratively, like this jLINQ example:
http://somewebguy.wordpress.com/2010/02/14/jlinq-in-mongodb-...