How does mongoDB actually work? [duplicate]

Question

Possible Duplicate:
How to represent the data for threaded comments(along with comment voting) in mongodb?

I come from mysql world and have decided to learn to use mongoDB. My upcoming project will be simmilar to Reddit.com with multi level commenting and voting. Can you please guide me to a good resource to understand how to build apps using mongodb? I understand how basic document storage works, but can't wrap my head around how I would actually store tree of comments and user information in one document and have it update if someone updates their user info. So basically I am looking for a guide of migrating from mysql to mongodb.

Any advice/guidance is greatly appreciated.

Answer 1

Some rules of thumb that I have found useful are this:

• If there is only one logical copy of a piece of information, it should be in one document (for example, if you have comments on a post, the simplest method is to embed them in the post)

• If you would denormalize data in SQL land into some other table to avoid joins and whatnot, the same behavior applies in document storage: denormalize from one "main" location into copies in other locations. The copies should be thought of as copies, and not origin information, so they can be overwritten with future denormalization actions.

• If you have to access one canonical set of data, like a user account, from multiple locations, store references as ObjectIds in mongodb, then execute a second query for the related document. You must be aware in your application that the second query is not a join, and will not lock both documents to ensure consistency, so there may be inconsistencies in the results.

Essentially, you should think of your database as consistent at the document level. Any query of related documents may be inconsistent, so if you need consistency, you can denormalize that data into one document.

If you need the user account to be exactly consistent with your comments, you will have to copy the relevant information next to your comments at the same time that you write the comments into the document. This means you have to think about consistency at the application level, all the time. If not, as I suspect is the case, just issue another query for the user.

If you are concerned about performance in querying for data on all of the users that participate in your page, I would recommend copying over some data from the user account next to the comment, but only read from this copy - you should write to your original user accounts.

That's all that comes to mind for now, but I may edit as things occur to me :)

Answer 2

The reason why you are having trouble wrapping your head around it is because MongoDB is not a relational database, it is a document-oriented database. For something simple like a tree of comments with a very set structure and a one-to-many relationship you would probably be best off sticking with MySQL. User profile might be an interesting thing to use MongoDB for, but again, if it is very structured you might be better off with MySQL.

You might want to determine which aspects of the project are best suited for a documented-oriented database (IE: unstructured data), and which aspects would best to used a more traditional relational database, and then use both!

A previous question which I asked has a good overview of both: Are document-oriented databases meant to replace relational databases?

I have also been using both on projects with a lot of success, although it does take a substantial amount of initial setup as most frameworks do not allow for implementing both too easily.