I’m trying to wrap my head around CouchDB. I’m trying to switch off of MongoDB to CouchDB because I think the concept of views are more appealing to me. In CouchDB it looks like all records are stored in a single database. There is no concept of collections or anything, like in MongoDB. So, when storing different data entities such as users, blog posts, comments, etc, how do you differentiate between them from within your map reduce functions? I was thinking about just using some sort of type property and for each item I’d just have to make sure to specify the type, always. This line of thought was sort of reinforced when I read over the CouchDB cookbook website, in which an example does the same thing.
Is this the most reliable way of doing this, or is there a better method? I was thinking of alternatives, and I think the only other alternative way is to basically embed as much as I can into logical documents. Like, the immediate records inside of the database would all be User records, and each User would have an array of Posts, in which you just add all of the Posts to. The downside here would be that embedded documents wouldn’t get their own id properties, correct?
Using
typeis convenient and fast when creatingviews. Alternatively you can consider using a part of the JSON document. I.e., instead of defining:You would have:
And then in the view for emitting documents containing
userinformation, instead of using:You would write:
As you can see there is not much difference. As you have already realized 1st approach is the most widely used but second (afaik) is well accepted.
Regarding the question of storing all
Postsof oneUserin one single document. Depends on how you plan to update your document. Remember that you need to write the whole document each time that you update (unless you useattachments). That means that each time a user writes a newPostyou need to retrieve the document containing thearrayofPosts, add/modify one element and update the document. Probably too much (heavy).