MongoDB是一種面向Document的NoSQL數(shù)據(jù)庫，如果我們還是按照RDB的方式來思考MongoDB的數(shù)據(jù)建模，則不能有效地利用MongoDB的優(yōu)勢;然而，我們也不能因為Document的靈活性，就可以在設(shè)計之初放任自流。

適度的建模是非常有必要的，尤其對于相對復雜的關(guān)聯(lián)關(guān)系。因為在MongoDB中，處理這種關(guān)聯(lián)關(guān)系既可以使用Link，也可以使用Embedded。

我們要評價一種決策，不能將其與具體的上下文割裂開來做判斷，那種單純說A技術(shù)要比B技術(shù)好的做法，就像小孩子看卡通片里的人物只知道說誰是好人誰是壞人一般的幼稚。世界上沒有一種***至善的技術(shù)，關(guān)鍵還是要結(jié)合場景來看使用是否得法。

例如使用Embedded方式，就各有優(yōu)缺點。舉例來說，倘若我們采用Embedded方式將Addresses作為Person對象內(nèi)部的數(shù)組：

 
 
 
 

  
  
  
  
{
  
  
  
  
  name: 'Kate Monster',
  
  
  
  
  ssn: '123-456-7890',
  
  
  
  
  addresses : [
  
  
  
  
     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
  
  
  
  
     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
  
  
  
  
  ]
  
  
  
  
}
 
 
 
 

當我們在查詢Person的信息時，要獲取其內(nèi)嵌的屬性細節(jié)，我們無需再執(zhí)行多次查詢。倘若我們改變一下領(lǐng)域場景，需要開發(fā)一個任務(wù)跟蹤系統(tǒng)。如果我們將Tasks的信息嵌入到Person對象中，當我們面對以下需求：

• 顯示所有明天到期的任務(wù)
• 顯示所有未完成的任務(wù)

采用這種Embedded就不那么令人愉快了。

如果采用Link方式，情況就完全不同了：

 
 
 
 

  
  
  
  
//Tasks
  
  
  
  
[
  
  
  
  
    {
  
  
  
  
        _id: ObjectID('AAAA'),
  
  
  
  
        task_number: 1234,
  
  
  
  
        taks_name: 'Prepare MongoDB environment',
  
  
  
  
        due_date: '2017-01-15'
  
  
  
  
    },
  
  
  
  
    {
  
  
  
  
        _id: ObjectID('BBBB'),
  
  
  
  
        task_number: 1235,
  
  
  
  
        taks_name: 'Import Test Data',
  
  
  
  
        due_date: '2017-02-15'
  
  
  
  
    },
  
  
  
  
]
  
  
  
  

  
  
  
  
//Persons
  
  
  
  
{
  
  
  
  
  name: 'Kate Monster',
  
  
  
  
  role: 'Manager',
  
  
  
  
  tasks : [
  
  
  
  
    ObjectID('AAAA'),
  
  
  
  
    ObjectID('BBBB')
  
  
  
  
  ]
  
  
  
  
}
 
 
 
 

有得必有失，當我們需要查詢Person承擔的Tasks時，采用這種方式，就需要采用application-level join方式執(zhí)行兩次查詢。

這種建模方式還帶來另一種可能，就是原本Person->Tasks的one-to-N關(guān)系就可以變?yōu)镹-to-N關(guān)系，因為一個Task可以被多個Person所擁有。如果采用Embedded方式，則會導致Task數(shù)據(jù)的冗余。

在文章 6 Rules of Thumb for MongoDB Schema Design中，作者將這種1對N關(guān)聯(lián)實現(xiàn)的判斷依據(jù)劃分為三種形式：

• one-to-few
• one-to-many
• one-to-squillions

但我認為該怎么實現(xiàn)關(guān)聯(lián)，應(yīng)該從Entity之間的領(lǐng)域關(guān)系來判斷，我們可以引入DDD的Aggregation設(shè)計概念作為建模的依據(jù)。簡單來說，如果使用Embedded，可以認為該Entity處于Aggregation邊界之內(nèi)，對外應(yīng)該通過Aggregation Root來訪問。文章 6 Rules of Thumb for MongoDB Schema Design的說法就是：

Will the entities on the “N” side of the One-to-N ever need to stand alone?

如果是Stand Alone，就意味著該Entity可以成為一個獨立的Aggregation，然后再通過ID與另外一個Aggregate關(guān)聯(lián)。

在SegmentFault上則有人做了如此總結(jié)：

• FirstClass (比如“User”這種) 應(yīng)該用獨立的Collection
• "條目類型"的，應(yīng)該 embedded
• 兩個模型之間如果是包含關(guān)系，用 embedded
• 多對多關(guān)系，用 link(類似sql里面的foregin key)
• 如果一個模型，其可能存的對象很少，那么就用獨立的collection，這樣有助于mongodb server做緩存
• embedded方式不利于做復雜的關(guān)聯(lián)，復雜的查詢
• embedded方式性能很有優(yōu)勢，如果你有“性能”方面的要求，可以考慮用embbed

【本文為專欄作者“張逸”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

網(wǎng)頁題目：MongoDB的數(shù)據(jù)建模
鏈接地址：http://uogjgqi.cn/article/coessgh.html