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.