Databases Reference
In-Depth Information
However, if you normalize, your application must do an extra query every time it wants
to find out what
fruit
is (
Figure 1-2
). If your application cannot afford this performance
hit and it will be OK to reconcile inconsistencies later, you should denormalize.
Figure 1-2. A denormalized schema. The value for fruit is stored in both the food and meals collections.
This is a trade-off:
you cannot have both the fastest performance and guaranteed imme-
diate consistency
. You must decide which is more important for your application.
Example: a shopping cart order
Suppose that we are designing a schema for a shopping cart application. Our applica-
tion stores orders in MongoDB, but what information should an order contain?
Normalized schema
A product:
{
"_id" :
productId
,
"name" :
name
,
"price" :
price
,
"desc" :
description
}
An order:
{
"_id" :
orderId
,
"user" :
userInfo
,
"items" : [
productId1
,
productId2
,
productId3
]
}
We store the
_id
of each item in the order document. Then, when we display the
contents of an order, we query the
orders
collection to get the correct order and
then query the
products
collection to get the products associated with our list of
_id
s.
There is no way to get a the full order in a single query with this schema
.
