Looking for Help Understanding Mongo DB Data Organization

Question

I am trying to understand the concept of document storage and fail to see how it would apply to some situations. For example, in the case of a CMS/blog engine there may be data in the form of:

• Posts
• Categories
• Users
• Comments

In something such as MySQL one might have a table for each, then a join table for each set of related data. ie posts_table , categories_table , categories_posts_table

In this case, posts_table would contain the post data, categories_table would contain the categories data and categories_posts_table would contain 2 foreign keys used to associate a specific category to a specific post.

How does this translate into something like mongodb?

The only way i can see this setup being structured in mongo is something like:

• posts_collection

The output of a single bson document might look similar to:

  {
     "title" : "title",
     "body" : "blah body",
     "categories" : [
                 "category1",
                 "category2"
               ]
  }

That makes sense, but it seems like categories are going to be duplicated all over the place. With out some sort of relation, you could never be able to simply change the category name and have it reflected across all of your blog posts (?).

Additionally what if these were like binary documents that took up a lot of space? Instead of duplicating the same image over and over it seems like a relationship would work better?

I guess this is a pretty open question, but i was looking for anyone's input on how i should mentally take apart a problem to tell if it should fit in a db like mongo or not. And equally important is how does one structure data correctly?

I have not touched on Users but it seems like EVERYTHING in this would ultimately end up as an embedded document inside of a User's collection since the User kind of starts everything.

thanks a lot.

Answer 1

What's interesting about document databases is that you really need to think about how your data is going to be used. Storing the same information in multiple places (denormalization) is fine in a document database. So you're correct when you say you could have a root User document with everything else embedded in it.

From my limited experience, there's not a "right" way to model a particular set of data, it's more about how that data is going to be used in the future.

It IS possible to reference another documents. For example if you want a Posts collection and have each Post reference a User document in the Users collection. Take a look at this article about Embed vs. Reference .