On Nov 12, 2013, at 10:56 AM, Kevin Coombes <[email protected]> wrote:
> It is also clear that part of what drives her to this conclusion is the > design she uses of just a few massive documents. ... And > so I think she fails to see the ability of well-written views to > aggregate documents on the fly. Right. I don’t know MongoDB, but the post indicates that she doesn’t understand how to effectively query document databases: >> This eliminates our duplication problem. When user data changes, there’s >> only one document that gets rewritten. However, we’ve created a new problem >> for ourselves. Because we’ve moved some data out of the activity streams, we >> can no longer construct an activity stream from a single document. This is >> less efficient and more complex. Constructing an activity stream now >> requires us to 1) retrieve the stream document, and then 2) retrieve all the >> user documents to fill in names and avatars. >> What’s missing from MongoDB is a SQL-style join operation, which is the >> ability to write one query that mashes together the activity stream and all >> the users that the stream references. Because MongoDB doesn’t have this >> ability, you end up manually doing that mashup in your application code, >> instead. Map/reduce views answer those issues. I don’t know if MongoDB has them, but I assume it has something of about the same level of power since it is being used for real-world applications where you have to do exactly this kind of querying. This seems like a very common style of tech blog post, along the lines of “I know X very well. I’ve been using Y, which is very different from X. I tried to solve a problem in Y using the techniques I know from X, and it didn’t work. Therefore Y SUCKS and no one should use it." —Jens
