Because any document can be put into any collection, the question often arises: “Why do we need separate collections at
all?” It’s a good question—with no need for separate schemas for different kinds of documents, why should we use more than one collection? There are several good reasons:
• Keeping different kinds of documents in the same collection can be a nightmare
for developers and admins. Developers need to make sure that each query is only
returning documents of a certain kind or that the application code performing a
query can handle documents of different shapes. If we’re querying for blog posts,
it’s a hassle to weed out documents containing author data.
• It is much faster to get a list of collections than to extract a list of the types in a
collection. For example, if we had a type key in the collection that said whether
each document was a “skim,” “whole,” or “chunky monkey” document, it would
be much slower to find those three values in a single collection than to have three
separate collections and query for their names (see “Subcollections”
on page 8).
• Grouping documents of the same kind together in the same collection allows for
data locality. Getting several blog posts from a collection containing only posts will
likely require fewer disk seeks than getting the same posts from a collection containing
posts and author data.
• We begin to impose some structure on our documents when we create indexes.
(This is especially true in the case of unique indexes.) These indexes are defined
per collection. By putting only documents of a single type into the same collection,
we can index our collections more efficiently.