原文：6 Rules of Thumb for MongoDB Schema Design: Part 1
By William Zola, Lead Technical Support Engineer at MongoDB
“我有豐富的sql使用經(jīng)驗，但是我是個MongoDB的初學(xué)者。我應(yīng)該如何在MongoDB中針對一對多關(guān)系進行建模？”這是我被問及最多的問題之一。
我沒法簡單的給出答案，因為這有很多方案去實現(xiàn)。接下來我會教導(dǎo)你如何針對一對多進行建模。
這個話題有很多內(nèi)容需要討論，我會用三個部分進行說明。在第一部分，我會討論針對一對多關(guān)系建模的三種基礎(chǔ)方案。在第二部分我將會覆蓋更多高級內(nèi)容，包括反范式化和雙向引用。在最后一部分，我將會回顧各種選擇，并給出做決定時需要考慮的因素。
很多初學(xué)者認(rèn)為在MongoDB中針對一對多建模唯一的方案就是在父文檔中內(nèi)嵌一個數(shù)組子文檔，但是這是不準(zhǔn)確的。因為你可以在MongoDB內(nèi)嵌一個文檔不代表你就必須這么做。
當(dāng)你設(shè)計一個MongoDB數(shù)據(jù)庫結(jié)構(gòu)，你需要先問自己一個在使用關(guān)系型數(shù)據(jù)庫時不會考慮的問題：這個關(guān)系中集合的大小是什么樣的規(guī)模？你需要意識到一對很少，一對許多，一對非常多，這些細(xì)微的區(qū)別。不同的情況下你的建模也將不同。
Basics: Modeling One-to-Few
一對很少
針對個人需要保存多個地址進行建模的場景下使用內(nèi)嵌文檔是很合適，可以在person文檔中嵌入addresses數(shù)組文檔：
這種設(shè)計具有內(nèi)嵌文檔設(shè)計中所有的優(yōu)缺點。最主要的優(yōu)點就是不需要單獨執(zhí)行一條語句去獲取內(nèi)嵌的內(nèi)容。最主要的缺點是你無法把這些內(nèi)嵌文檔當(dāng)做單獨的實體去訪問。
例如，如果你是在對一個任務(wù)跟蹤系統(tǒng)進行建模，每個用戶將會被分配若干個任務(wù)。內(nèi)嵌這些任務(wù)到用戶文檔在遇到“查詢昨天所有的任務(wù)”這樣的問題時將會非常困難。我會在下一篇文章針對這個用例提供一些適當(dāng)?shù)脑O(shè)計。
Basics: One-to-Many
一對許多
以產(chǎn)品零件訂貨系統(tǒng)為例。每個商品有數(shù)百個可替換的零件，但是不會超過數(shù)千個。這個用例很適合使用間接引用---將零件的objectid作為數(shù)組存放在商品文檔中(在這個例子中的ObjectID我使用更加易讀的2字節(jié)，現(xiàn)實世界中他們可能是由12個字節(jié)組成的)。
每個零件都將有他們自己的文檔對象
每個產(chǎn)品的文檔對象中parts數(shù)組中將會存放多個零件的ObjectID?：
在獲取特定產(chǎn)品中所有零件，需要一個應(yīng)用層級別的join
為了能快速的執(zhí)行查詢，必須確保products.catalog_number有索引。當(dāng)然由于零件中parts._id一定是有索引的，所以這也會很高效。
這種引用的方式是對內(nèi)嵌優(yōu)缺點的補充。每個零件是個單獨的文檔，可以很容易的獨立去搜索和更新他們。需要一條單獨的語句去獲取零件的具體內(nèi)容是使用這種建模方式需要考慮的一個問題（請仔細(xì)思考這個問題，在第二章反反范式化中，我們還會討論這個問題）
這種建模方式中的零件部分可以被多個產(chǎn)品使用，所以在多對多時不需要一張單獨的連接表。
Basics: One-to-Squillions
一對非常多
我們用一個收集各種機器日志的例子來討論一對非常多的問題。由于每個mongodb的文檔有16M的大小限制，所以即使你是存儲ObjectID也是不夠的。我們可以使用很經(jīng)典的處理方法“父級引用”---用一個文檔存儲主機，在每個日志文檔中保存這個主機的ObjectID。
以下是個和第二中方案稍微不同的應(yīng)用級別的join用來查找一臺主機最近5000條的日志信息
所以，即使這種簡單的討論也有能察覺出mongobd的建模和關(guān)系模型建模的不同之處。你必須要注意一下兩個因素：
Will the entities on the “N” side of the One-to-N ever need to stand alone?
一對多中的多是否需要一個單獨的實體。
What is the cardinality of the relationship: is it one-to-few; one-to-many; or one-to-squillions?
這個關(guān)系中集合的規(guī)模是一對很少，很多，還是非常多。
Based on these factors, you can pick one of the three basic One-to-N schema designs:
基于以上因素來決定采取一下三種建模的方式
一對很少且不需要單獨訪問內(nèi)嵌內(nèi)容的情況下可以使用內(nèi)嵌多的一方。
一對多且多的一端內(nèi)容因為各種理由需要單獨存在的情況下可以通過數(shù)組的方式引用多的一方的。
一對非常多的情況下，請將一的那端引用嵌入進多的一端對象中。
下一次我們將會看到如何使用雙向關(guān)系和反范式化去提升以上三種基本方案的性能。
Part 2: Two-way referencing and denormalization
Part 3: Your guide through the rainbow
相關(guān)文章：
MongoDB數(shù)據(jù)庫設(shè)計中6條重要的經(jīng)驗法則，part 2（每日一譯：2014-07-24）
MongoDB數(shù)據(jù)庫設(shè)計中6條重要的經(jīng)驗法則，part 3（每日一譯：2014-07-25）
