Databases Reference
In-Depth Information
Comments are often a weird edge case that varies on the application. Comments
should, for most applications, be stored embedded in their parent document. However,
for applications where the comments are their own entity or there are often hundreds
or more, they should be stored as separate documents.
As another example, suppose we are creating an application solely for the purpose of
commenting. The image board example in
“Tip #3: Try to fetch data in a single
query” on page 5
is like this; the primary content is the comments. In this case, we'd
want comments to be separate documents.
Tip #7: Pre-populate anything you can
If you know that your document is going to need certain fields in the future, it is more
efficient to populate them when you first insert it than to create the fields as you go.
For example, suppose you are creating an application for site analytics, to see how many
users visited different pages every minute over a day. We will have a pages collection,
where each document represents a 6-hour slice in time for a page. We want to store
info per minute and per hour:
{
"_id" :
pageId
,
"start" :
time
,
"visits" : {
"minutes" : [
[
num0
,
num1
, ...,
num59
],
[
num0
,
num1
, ...,
num59
],
[
num0
,
num1
, ...,
num59
],
[
num0
,
num1
, ...,
num59
],
[
num0
,
num1
, ...,
num59
],
[
num0
,
num1
, ...,
num59
]
],
"hours" : [
num0
, ...,
num5
]
}
}
We have a huge advantage here: we know what these documents are going to look like
from now until the end of time. There will be one with a start time of now with an entry
every minute for the next six hours. Then there will be another document like this, and
another one.
Thus, we could have a batch job that either inserts these “template” documents at a
non-busy time or in a steady trickle over the course of the day. This script could insert
documents that look like this, replacing
someTime
with whatever the next 6-hour interval
should be:
{
"_id" :
pageId
,
"start" :
someTime
,
"visits" : {
"minutes" : [
