

Translate MySQL to MongoDB MapReduce [pdf] - Jim_Neath
http://rickosborne.org/download/SQL-to-MongoDB.pdf

======
oliverkofoed
The SQL looks way easier (and shorter). I hope somebody will take it upon
themselves to write an sql-to-mongo-mapreduce compiler.

~~~
jgrahamc
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.

~~~
simonw
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.

~~~
jbellis
Bingo. That was exactly what we were shooting for.

------
paulsmith
Did that chart just tell me to go fuck myself?

~~~
_pius
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.

~~~
paulsmith
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>

~~~
_pius
LOL, hadn't seen that before. Very apropos.

------
audionerd
The example given is in the lower level imperative javascript you'd use to
speak directly to MongoDB.

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-...](http://somewebguy.wordpress.com/2010/02/14/jlinq-in-mongodb-oh-
snap/)

------
mrkurt
SQL is really nice for querying sets. There's no reason Mongo has to go
without its query capabilities, really.

~~~
_pius
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?

