Databases Reference
In-Depth Information
As your application becomes more complicated and users and managers request more
features, do not despair if you need to make more than one query per application unit.
The one-query-per-unit goal is a good starting point and metric to judging your initial
schema, but the real world is messy. With any sufficiently complex application, you're
probably going to end up making more than one query for one of your application's
more ridiculous features.
Tip #4: Embed dependent fields
When considering whether to embed or reference a document, ask yourself if you'll be
querying for the information in this field by itself, or only in the framework of the larger
document. For example, you might want to query on a tag, but only to link back to the
posts with that tag, not for the tag on its own. Similarly with comments, you might
have a list of recent comments, but people are interested in going to the post that
inspired the comment (unless comments are first-class citizens in your application).
If you have been using a relational database and are migrating an existing schema to
MongoDB, join tables are excellent candidates for embedding. Tables that are basically
a key and a value—such as tags, permissions, or addresses—almost always work better
embedded in MongoDB.
Finally, if only one document cares about certain information, embed the information
in that document.
Tip #5: Embed “point-in-time” data
As mentioned in the orders example in
“Tip #1: Duplicate data for speed, reference
data for integrity” on page 1
, you don't actually want the information in the order to
change if a product, say, goes on sale or gets a new thumbnail. Any sort of information
like this, where you want to snapshot the data at a particular time, should be embedded.
Another example from the order document: the address fields also fall into the “point-
in-time” category of data. You don't want a user's past orders to change if he updates
his profile.
Tip #6: Do not embed fields that have unbound growth
Because of the way MongoDB stores data, it is fairly inefficient to constantly be ap-
pending information to the end of an array. You want arrays and objects to be fairly
constant in size during normal usage.
Thus, it is fine to embed 20 subdocuments, or 100, or 1,000,000, but do so up front.
Allowing a document to grow a lot as it is used is probably going to be slower than
you'd like.
