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

適度的建模是非常有必要的，尤其對(duì)于相對(duì)復(fù)雜的關(guān)聯(lián)關(guān)系。因?yàn)樵贛ongoDB中，處理這種關(guān)聯(lián)關(guān)系既可以使用Link，也可以使用Embedded。

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

例如使用Embedded方式，就各有優(yōu)缺點(diǎn)。舉例來(lái)說(shuō)，倘若我們采用Embedded方式將Addresses作為Person對(duì)象內(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' } 
  ] 
} 

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

• 顯示所有明天到期的任務(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') 
  ] 
} 

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

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

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

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

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

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

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

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

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

戳這里，看該作者更多好文