MongoDB Database Design: Large vs Small Documents

For relational databases, the approach is to have as many tables as you need to create the perfectly normalized database design. For MongoDB (and true to same or less extent for other NoSQL databases due to differing indexing capabilities), it seems the recommended approach is when in doubt, use less large documents (i.e. the embedding rather than linking approach).

Unlike other NoSQL databases, you don't have to create many small collections just because you have to query by with different fields as keys, as you can use indexing to solve this problem with MongoDB.  Furthermore, MongoDB allows indexes to be created on objects nested within the document hierarchy.

I can think of the following key benefits of using large documents:

• Less joins, less follow up queries, write much less code
• Operations within a single document are atomic, don't have to worry about writing to 3 separate documents and then what happens if one of the writes fail

The main downside to large documents is when you have to run queries that result in table-scans. You'll just have to make sure that you have indexes covering all possible queries you need to make.

References:

• http://www.mongodb.org/display/DOCS/Schema+Design