Principles for Modeling CouchDB Documents

Question

I have a question that I\'ve been trying to answer for some time now but can\'t figure out:

How do you design, or divide up, CouchDB documents?

Take a Blog P

Answer 1

I think Jake's response nails one of the most important aspects of working with CouchDB that may help you make the scoping decision: conflicts.

In the case where you have comments as an array property of the post itself, and you just have a 'post' DB with a bunch of huge 'post' documents in it, as Jake and others correctly pointed out you could imagine a scenario on a really popular blog post where two users submit edits to the post document simultaneously, resulting in a collision and a version conflict for that document.

ASIDE: As this article points out, also consider that each time you are requesting/updating that doc you have to get/set the document in its entirety, so passing around a massive documents that either represent the entire site or a post with a lot of comments on it can become a problem you would want to avoid.

In the case where posts are modeled separately from comments and two people submit a comment on a story, those simply become two "comment" documents in that DB, with no issue of conflict; just two PUT operations to add two new comments to the "comment" db.

Then to write the views that give you back the comments for a post, you would pass in the postID and then emit all the comments that reference that parent post ID, sorted in some logical ordering. Maybe you even pass in something like [postID,byUsername] as the key to the 'comments' view to indicate the parent post and how you want the results sorted or something along those lines.

MongoDB handles documents a bit differently, allowing indexes to be built on sub-elements of a document, so you might see the same question on the MongoDB mailing list and someone saying "just make the comments a property of the parent post".

Because of the write locking and single-master nature of Mongo, the conflicting revision issue of two people adding comments wouldn't spring up there and the query-ability of the content, as mentioned, isn't effected too poorly because of sub-indexes.

That being said, if your sub-elements in either DB are going to be huge (say 10s of thousands of comments) I believe it is the recommendation of both camps to make those separate elements; I have certainly seen that to be the case with Mongo as there are some upper bound limits on how big a document and its subelements can be.