原文：6 Rules of Thumb for MongoDB Schema Design: Part 1

By William Zola, Lead Technical Support Engineer at MongoDB

“我有豐富的sql使用經(jīng)驗(yàn)，但是我是個(gè)MongoDB的初學(xué)者。我應(yīng)該如何在MongoDB中針對(duì)一對(duì)多關(guān)系進(jìn)行建模？”這是我被問及最多的問題之一滨嘱。

我沒法簡單的給出答案，因?yàn)檫@有很多方案去實(shí)現(xiàn)浸间。接下來我會(huì)教導(dǎo)你如何針對(duì)一對(duì)多進(jìn)行建模太雨。

這個(gè)話題有很多內(nèi)容需要討論，我會(huì)用三個(gè)部分進(jìn)行說明魁蒜。在第一部分囊扳，我會(huì)討論針對(duì)一對(duì)多關(guān)系建模的三種基礎(chǔ)方案。在第二部分我將會(huì)覆蓋更多高級(jí)內(nèi)容兜看，包括反范式化和雙向引用锥咸。在最后一部分，我將會(huì)回顧各種選擇细移，并給出做決定時(shí)需要考慮的因素搏予。

很多初學(xué)者認(rèn)為在MongoDB中針對(duì)一對(duì)多建模唯一的方案就是在父文檔中內(nèi)嵌一個(gè)數(shù)組子文檔，但是這是不準(zhǔn)確的弧轧。因?yàn)槟憧梢栽贛ongoDB內(nèi)嵌一個(gè)文檔不代表你就必須這么做雪侥。

當(dāng)你設(shè)計(jì)一個(gè)MongoDB數(shù)據(jù)庫結(jié)構(gòu)，你需要先問自己一個(gè)在使用關(guān)系型數(shù)據(jù)庫時(shí)不會(huì)考慮的問題：這個(gè)關(guān)系中集合的大小是什么樣的規(guī)模精绎？你需要意識(shí)到一對(duì)很少速缨，一對(duì)許多，一對(duì)非常多代乃，這些細(xì)微的區(qū)別旬牲。不同的情況下你的建模也將不同。

Basics: Modeling One-to-Few

一對(duì)很少

針對(duì)個(gè)人需要保存多個(gè)地址進(jìn)行建模的場(chǎng)景下使用內(nèi)嵌文檔是很合適襟己，可以在person文檔中嵌入addresses數(shù)組文檔：

這種設(shè)計(jì)具有內(nèi)嵌文檔設(shè)計(jì)中所有的優(yōu)缺點(diǎn)引谜。最主要的優(yōu)點(diǎn)就是不需要單獨(dú)執(zhí)行一條語句去獲取內(nèi)嵌的內(nèi)容。最主要的缺點(diǎn)是你無法把這些內(nèi)嵌文檔當(dāng)做單獨(dú)的實(shí)體去訪問擎浴。

例如员咽，如果你是在對(duì)一個(gè)任務(wù)跟蹤系統(tǒng)進(jìn)行建模，每個(gè)用戶將會(huì)被分配若干個(gè)任務(wù)贮预。內(nèi)嵌這些任務(wù)到用戶文檔在遇到“查詢昨天所有的任務(wù)”這樣的問題時(shí)將會(huì)非常困難贝室。我會(huì)在下一篇文章針對(duì)這個(gè)用例提供一些適當(dāng)?shù)脑O(shè)計(jì)。

Basics: One-to-Many

一對(duì)許多

以產(chǎn)品零件訂貨系統(tǒng)為例仿吞。每個(gè)商品有數(shù)百個(gè)可替換的零件滑频，但是不會(huì)超過數(shù)千個(gè)。這個(gè)用例很適合使用間接引用---將零件的objectid作為數(shù)組存放在商品文檔中(在這個(gè)例子中的ObjectID我使用更加易讀的2字節(jié)唤冈，現(xiàn)實(shí)世界中他們可能是由12個(gè)字節(jié)組成的)峡迷。

每個(gè)零件都將有他們自己的文檔對(duì)象

每個(gè)產(chǎn)品的文檔對(duì)象中parts數(shù)組中將會(huì)存放多個(gè)零件的ObjectID?：

在獲取特定產(chǎn)品中所有零件，需要一個(gè)應(yīng)用層級(jí)別的join

為了能快速的執(zhí)行查詢，必須確保products.catalog_number有索引绘搞。當(dāng)然由于零件中parts._id一定是有索引的彤避，所以這也會(huì)很高效。

這種引用的方式是對(duì)內(nèi)嵌優(yōu)缺點(diǎn)的補(bǔ)充夯辖。每個(gè)零件是個(gè)單獨(dú)的文檔琉预，可以很容易的獨(dú)立去搜索和更新他們。需要一條單獨(dú)的語句去獲取零件的具體內(nèi)容是使用這種建模方式需要考慮的一個(gè)問題（請(qǐng)仔細(xì)思考這個(gè)問題蒿褂，在第二章反反范式化中圆米，我們還會(huì)討論這個(gè)問題）

這種建模方式中的零件部分可以被多個(gè)產(chǎn)品使用，所以在多對(duì)多時(shí)不需要一張單獨(dú)的連接表啄栓。

Basics: One-to-Squillions

一對(duì)非常多

我們用一個(gè)收集各種機(jī)器日志的例子來討論一對(duì)非常多的問題娄帖。由于每個(gè)mongodb的文檔有16M的大小限制，所以即使你是存儲(chǔ)ObjectID也是不夠的谴供。我們可以使用很經(jīng)典的處理方法“父級(jí)引用”---用一個(gè)文檔存儲(chǔ)主機(jī)块茁，在每個(gè)日志文檔中保存這個(gè)主機(jī)的ObjectID。

以下是個(gè)和第二中方案稍微不同的應(yīng)用級(jí)別的join用來查找一臺(tái)主機(jī)最近5000條的日志信息

所以桂肌，即使這種簡單的討論也有能察覺出mongobd的建模和關(guān)系模型建模的不同之處数焊。你必須要注意一下兩個(gè)因素：

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

一對(duì)多中的多是否需要一個(gè)單獨(dú)的實(shí)體。

What is the cardinality of the relationship: is it one-to-few; one-to-many; or one-to-squillions?

這個(gè)關(guān)系中集合的規(guī)模是一對(duì)很少崎场，很多佩耳，還是非常多。

Based on these factors, you can pick one of the three basic One-to-N schema designs:

基于以上因素來決定采取一下三種建模的方式

一對(duì)很少且不需要單獨(dú)訪問內(nèi)嵌內(nèi)容的情況下可以使用內(nèi)嵌多的一方谭跨。

一對(duì)多且多的一端內(nèi)容因?yàn)楦鞣N理由需要單獨(dú)存在的情況下可以通過數(shù)組的方式引用多的一方的干厚。

一對(duì)非常多的情況下，請(qǐng)將一的那端引用嵌入進(jìn)多的一端對(duì)象中螃宙。

下一次我們將會(huì)看到如何使用雙向關(guān)系和反范式化去提升以上三種基本方案的性能蛮瞄。

Part 2: Two-way referencing and denormalization

Part 3: Your guide through the rainbow

相關(guān)文章：

MongoDB數(shù)據(jù)庫設(shè)計(jì)中6條重要的經(jīng)驗(yàn)法則，part 2（每日一譯：2014-07-24）

MongoDB數(shù)據(jù)庫設(shè)計(jì)中6條重要的經(jīng)驗(yàn)法則谆扎，part 3（每日一譯：2014-07-25）