![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
Challenge: list the nodes of a user ordered by comment count. Sounds simple but the uid is stored in the node table and the comment count is in node_comment_statistics and beccause of that, this query can not be indexed and will therefore be always slow. Of course, you can begin to denormalize but do you want to keep a denormalized copy of your data for every kind of query? That's not a solution, that's a kludge and an ugly one.
With MongoDB (if you are unfamiliar, you can read the tutorial and /or test drive it), this problem simply does not exist. The complete node becomes a document and is stored in one collection. And even if different node types have different fields on them, that's still not a problem, because there is no schema definition in MongoDB, you can store and index whatever you want. If you index on a property which does not exist in a document then that's simply skipped.
This a wonderful world, isnt it? Of course, there are challenges here as well. There are no JOINs so if you want list nodes belonging to users whose usernames starts with "Ab" then you are back in denormalization land -- you need to store the username into the node collection. However, I must say that this kind of query is way, way more rare than the kind that gave you headaches with SQL.
Commenting on this Story is closed.
«you need to store the username into the node collection. » Not (really) true.
With a map.reduce function (for the SQLists: that is a routine, in a programming language that can be compared to a "View" in MySQL or Group by, or... joins).
Basically in noSQL, you would fetch all reduced documents (nodes) in one array and all reduced other documents (persons) in another. Your multiple map reduce then walks trough them and combines them.
In reality this is a tad harder then it sounds here, but that would be it.
But also, in your example, you would probably opt for storing the comments inside the nodes (after all: are they not just fields with special metadata on a node? :))
So, yes. Joins are hard. But not needed. which is the point of NoSQL.
I've been keeping an eye on this "No SQL" thing… I don't really get how we're supposed to just get over not being able to JOIN. Maybe I'm missing something, but doesn't that completely break many parts of Drupal? Contrib, too - you won't be able to make but the most basic Views if you can't JOIN. How can any of these No SQL systems be ready for prime time use before they support JOINs?
Also, the name "MongoDB" is horrible and probably won't make it far in the business world. I'm rather fond of the name for "Tokyo Tyrant," though.
Fashion is a lasting topic! And fashion long lives!