Question

I have 1 collection called Visit, in it I save documents with information about visit referrer, page, keyword, dates, so on.

I think Keyword can be considered a collection on it’s own, the same for Page.
This will force me to create different collections but I’m not sure if this is the right way to go.

In a traditional DB model, they will clearly be stored in separate tables connected with FK.

• But what about mongo ?
• Is it a good practice for keys to have the same value over and over again for different documents and just create a collection in this case ?

Answer 1

One of the benefits of MongoDB is its ability to embed documents.

It is perfectly reasonable for the documents in your Visits collection to contain Keyword and Page Sub-Documents.

The rule of thumb is embed documents for speed, normalize documents for consistency.

If you embed the Keyword and Page documents in your Visit document, your application will only have to make one query to retrieve all of the relevant information. (speed)

However, the drawback is that if the Keyword and/or Page information is updated, it will have to be updated in every other Visit document where it appears. If many different Visit documents will rely on the same Keyword and Page documents, it may be better to keep them in a separate collection, especially if they will be changed frequently. (consistency)

This is of course a generalization, and ultimately it is up to you, the application developer to decide which works best for your unique situation. There is additional information on Embedding versus Linking in the Mongo Document titled “Schema Design”
http://www.mongodb.org/display/DOCS/Schema+Design

You may also find the article “MongoDB Data Modeling and Rails” to be beneficial:
http://www.mongodb.org/display/DOCS/MongoDB+Data+Modeling+and+Rails
The example is given in Rails, but the theory on Document design applies to any language.

Good luck!