Database Reference
In-Depth Information
On the other hand, suppose we decided to use a normalized schema:
// db.posts schema
{
"_id"
:
"First Post"
,
"author"
:
"Rick"
,
"text"
:
"This is my first post"
}
// db.comments schema
{
"_id"
:
ObjectId
(...),
"post_id"
:
"First Post"
,
"author"
:
"Stuart"
,
"text"
:
"Nice post!"
}
Our query to retrieve all of Stuart's comments is now quite straightforward:
db
.
comments
.
find
({
"author"
:
"Stuart"
})
In general, if your application's query pattern is well-known and data tends to be accessed
in only one way, an embedded approach works well. Alternatively, if your application may
query data in many different ways, or you are not able to anticipate the patterns in which data
may be queried, a more “normalized” approach may be better. For instance, in our “linked”
schema, we're able to sort the comments we're interested in, or restrict the number of com-
ments returned from a query using
limit()
and
skip()
operators, whereas in the embedded
case, we're stuck retrieving all the comments in the same order they are stored in the post.
Referencing for Potentially High-Arity Relationships
Another factor that may weigh in favor of a more normalized model using document refer-
ences is when you have one-to-many relationships with very high or unpredictable
arity
. For
instance,apopularblogwithalargeamountofreaderengagementmayhavehundredsoreven
thousands of comments for a given post. In this case, embedding carries significant penalties
with it:
▪ The larger a document is, the more RAM it uses.
▪ Growing documents must eventually be copied to larger spaces.
