MongoDB: The Definitive Guide, 2nd Edition

Chapter 8. Application Design

This chapter covers designing applications to work effectively with MongoDB. It discusses:

• Trade-offs when deciding whether to embed data or to reference it

• Tips for optimizations

• Consistency considerations

• How to migrate schemas

• When MongoDB isn’t a good choice of data store

Normalization versus Denormalization

There are many ways of representing data and one of the most important issues is how much you should normalize your data. Normalization is dividing up data into multiple collections with references between collections. Each piece of data lives in one collection although multiple documents may reference it. Thus, to change the data, only one document must be updated. However, MongoDB has no joining facilities, so gathering documents from multiple collections will require multiple queries.

Denormalization is the opposite of normalization: embedding all of the data in a single document. Instead of documents containing references to one definitive copy of the data, many documents may have copies of the data. This means that multiple documents need to be updated if the information changes but that all related data can be fetched with a single query.

Deciding when to normalize and when to denormalize can be difficult: typically, normalizing makes writes faster and denormalizing makes reads faster. Thus, you need to find what trade-offs make sense for your application.

Examples of Data Representations

Suppose we are storing information about students and the ...