After spending a decade working with Lotus Domino, I think all of these people who are willingly going back to document style databases are insane.<p>Being able to fiddle with your schema on the fly isn't necessarily a good thing. Brainstorm, plan, execute. Or just slap another field on the end of the document. Whichever sounds better for the long term health of your data!
I love me some document based databases. But I find it ridiculous how much FUD there is out there about them. After being severely burned by some "It's not fully ACID" types in my organization I am seriously reluctant to even use them on projects where they are ideally suited. Sorry for the rant. I think they are wonderful tools, but I also think people should know about the political implications of using them in organizations where 'old fashioned' or conservative thinking might come in and ruin their day.
Some of these examples are not equivalent. For example,<p><pre><code> r
.db('dragonball')
.table('characters')
.filter(function(row){
return row('maxStrength').gt(700000).and(row('species').contains('Saiyan'));
})
.orderBy(r.desc('maxStrength'));
</code></pre>
presumably returns one row per character, whereas<p><pre><code> SELECT c.*
FROM characters c
INNER JOIN character_species cs ON c.id = cs.character_id
INNER JOIN species s ON cs.species_id = s.id
WHERE max_strength > 700000
AND s.name = 'Saiyan'
ORDER BY max_strength DESC;
</code></pre>
returns <i>at least</i> one row per character. Rather, the equivalent SQL (depending on what syntax is available) might be:<p><pre><code> SELECT c.*
FROM characters c
WHERE max_strength > 700000
AND EXISTS (SELECT NULL
FROM character_species cs
INNER JOIN species s ON cs.species_id = s.id
WHERE c.id = cs.character_id
AND s.name = 'Saiyan')
ORDER BY max_strength DESC;
</code></pre>
The above returns one row per character, no matter how many matching entries there are in `character_species` or `species`.<p>Pursuing this a little further then, suppose you wanted to expand your search to include humans and androids. In SQL, only a slight modification is needed:<p><pre><code> SELECT c.*
FROM characters c
WHERE max_strength > 700000
AND EXISTS (SELECT NULL
FROM character_species cs
INNER JOIN species s ON cs.species_id = s.id
WHERE c.id = cs.character_id
AND s.name IN ('Saiyan', 'Human', 'Android'))
ORDER BY max_strength DESC;
</code></pre>
I shudder to think what that would look like in functional form. Something like this?<p><pre><code> r
.db('dragonball')
.table('characters')
.filter(function(row){
return row('maxStrength').gt(700000).and(row('species').contains('Saiyan')).or(row('species').contains('Human')).or(row('species').contains('Android'));
})
.orderBy(r.desc('maxStrength'));
</code></pre>
But how would it know how to group the disjunctions?<p>In my very limited experience, examples like these always look so tantalizing until you start taking them a little further and then you quickly realize there's no such thing as a free lunch. In this case, you pay for the flexibility of RethinkDB with the expressiveness SQL.
I still struggle for why someone would go RethinkDB over Hardoop. If you have the "Big Data" issue for using a Non-SQL DB (Another struggle of mine to find a clear case for its use).<p>Why go RethinkDB when you limit what you can do with your data at the start. You can't do so things but the big one for me is you really can't do statistical analysis (Author pointed it out in the article). Why have a Non-SQL that really hinders the biggest selling point for the non-SQL DB? Wouldn't it just be better to use a SQL and expand the scheme horizontally???<p>Serious question that I don't understand.