1: Duplicate data for speed, reference data for integrity
?
http://books.google.com.hk/books?id=IZiyEX_2JtoC&printsec=frontcover&dq=50+Tips+and+Tricks+for+MongoDB+Developers&source=bl&ots=r0Zvm_DR75&sig=dn_LhVomqVEBPPrKXiSSRc2y3f4&hl=en&ei=Tzy9TdmXG4aevgPDkpnbBQ&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDcQ6AEwBTgK#v=onepage&q&f=false
上面是google里的该书的一些片段，结合safari上的被遮住的，能拼凑一些完整的出来
?
先来看下文章里给的例子，一般按照正常的数据库设计范式都是如此设计一个购物车订单
Normalized schema
A product:
{
?? ?"_id" : productId,
?? ?"name" : name,
?? ?"price" : price,
?? ?"desc" : description
}
An order:
?
{
?? ?"_id" : orderId,
?? ?"user" : userInfo,
?? ?"items" : [
?? ? ? ?productId1,
?? ? ? ?productId2,
?? ? ? ?productId3
?? ?]
}
?
这种设计的缺点：如果需要查询某个订单中商品的detail需要查询2次
?
以下是非常规范式设计：（数据冗余或者可以理解为tip里Duplicate data）
?
?
Denormalized schema
?
A product (same as previous):
{
?? ?"_id" : productId,
?? ?"name" : name,
?? ?"price" : price,
?? ?"desc" : description
}
An order:
{
?? ?"_id" : orderId,
?? ?"user" : userInfo,
?? ?"items" : [
?? ? ? ?{
?? ? ? ? ? ?"_id" : productId1,
?? ? ? ? ? ?"name" : name1,
?? ? ? ? ? ?"price" : price1
?? ? ? ?},
?? ? ? ?{
?? ? ? ? ? ?"_id" : productId2,
?? ? ? ? ? ?"name" : name2,
?? ? ? ? ? ?"price" : price2
?? ? ? ?},
?? ? ? ?{
?? ? ? ? ? ?"_id" : productId3,
?? ? ? ? ? ?"name" : name3,
?? ? ? ? ? ?"price" : price3
?? ? ? ?}
?? ? ]
}
优点是：查询基本订单与商品信息时只需要查询一次
缺点：修改商品信息时，需要在每个订单中修改
?
针对嵌入对象的选取原则可以考虑如下：
?
It is almost never worth
referencing seldom-changing data such as names, birth dates, stock symbols, and
addresses.
?
考虑一种使用场景，如果某种商品想临时改下价格，类似清仓活动，但是已有的订单是不希望做修改的（这不坑爹吗），这个时候用第2种就比较合适。
?
解释下 ：第一种设计就是tip里的reference data for integrity
?? ? ? ? ? 第二种设计就是tip里的Duplicate data for speed
?
针对以上2种设计，原文给出的总结
This is a trade-off: you cannot have both the fastest performance and guaranteed immediate consistency. You must decide which is more important for your application.
?
?
