本篇博客翻譯自： http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1?mkt_tok=3RkMMJWWfF9wsRonsq7Ldu%2FhmjTEU5z14uUsUKGxhokz2EFye%2BLIHETpodcMTcVnM7zYDBceEJhqyQJxPr3FLdcN0tJuRhTrCw%3D%3D 備注：本譯文不

本篇博客翻譯自：

http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1?mkt_tok=3RkMMJWWfF9wsRonsq7Ldu%2FhmjTEU5z14uUsUKGxhokz2EFye%2BLIHETpodcMTcVnM7zYDBceEJhqyQJxPr3FLdcN0tJuRhTrCw%3D%3D

備注：本譯文不是嚴格意義上的翻譯，只是在基于對該原文的理解之上，盡可能表達清楚。如有疑問或不妥，請參考原文。

很多剛從傳統SQL開發轉向MongoDB開發的朋友都會問到一個問題：如何用MongoDB表達傳統關系數據庫中的一對多（1 to n）關系？

基于MongoDB豐富的表達力，我們不能說我們必須采用一個標準的方法來進行1 to n的建模。稍后我們從3個具體場景來展開講解。

首先，我們將1 to n中的n進行場景細化。這個n究竟代表多大的量級呢？是幾個到幾十個？還是幾個到幾千個？還是成千上萬個？

1） 1 to n（n代表好幾個，或幾十個，反正不太多）

比如每個Person會有多個Address。此種情況下，我們采用最簡單的嵌入式文檔來建模。

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

優點：你不需要執行單獨的查詢就可以獲得某個Person的所有Address信息。

缺點：你無法像操作獨立文檔那樣來操作Address信息。你必須首先操作（比如查詢）Person文檔后，才有可能繼續操作Address。

在本實例中，我們不需要對Address進行獨立的操作，且Address信息只有在關聯到某一個具體Person后才有意義。所以結論是：采用這種embedded（嵌入式）建模是非常適合Person-Address場景的。

2）1 to n（n代表好些個，比如幾十個，甚至幾百個）

比如產品（Product）和零部件（part），每個產品會有很多個零部件。這種場景下，我們可以采用引用方式來建模，如下：

零部件（Part）：{ _id : ObjectID('AAAA'), partno : '123-aff-456', name : '#4 grommet', qty: 94, cost: 0.94, price: 3.99}
產品（Product）：

{ name : 'left-handed smoke shifter', manufacturer : 'Acme Corp', catalog_number: 1234, parts : [ // array of references to Part documents ObjectID('AAAA'), // reference to the #4 grommet above ObjectID('F17C'), // reference to a different Part ObjectID('D2AA'), // etc ]}

首先每個part作為單獨的文檔存在。每個產品中包含一個數組類型字段（parts），這個數組中存放的是所有該產品包含的零部件的編號（_id主鍵）。當你需要根據某一個產品編號查詢該產品包含的所有部件信息時，你可以執行以下操作：

> product = db.products.findOne({catalog_number: 1234}); // Fetch all the Parts that are linked to this Product> product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;

優點：部件是作為獨立文檔（document）存在的，你可以對某一部件進行獨立的操作，比如查詢或更新。

缺點：如上，你必須通過兩次查詢才能找到某一個產品所屬的所有部件信息。

在本例中，這個缺點是可以接受的，本身實現起來也不難。而且，通過這種建模，你可以輕易的將1 to n擴展到n to n，即一個產品可以包含多個部件，同時一個部件也可以被多個產品所引用（即同一部件可以被多個產品使用）。

3）1 to n（這個n代表很大的數值，比如成千上萬，甚至更大）

比如，每一個機器（host）會產生很大數量的日志信息（logmsg）。在這種情況下，如果你采用嵌入式建模，則一個host文檔會非常龐大，從而輕易超過MongoDB的文檔大小限制，所以不可行。如果你采用第二中方式建模，用數組來存放所有logmsg的_id值，這種方式同樣不可行，因為當日止很多時，即使單單引用objectId也會輕易超過文檔大小限制。所以此時，我們采用以下方式：

機器（hosts）：{ _id : ObjectID('AAAB'), name : 'goofy.example.com', ipaddr : '127.66.66.66'} 日志（logmsg）：{ time : ISODate("2014-03-28T09:42:41.382Z"), message : 'cpu is on fire!', host: ObjectID('AAAB') // Reference to the Host document}

綜上所述，在對1 to n關系建模時，我們需要考慮：

1）n代表的數量級很小，且n代表的實體不需要單獨操作時，可以采用嵌入式建模。

2）n代表的數量級比較大，或者n代表的實體需要單獨進行操作時，采用在1中用Array存放引用的方式建模。

3）n代表的數量級非常大時，我們沒有選擇，只能在n端添加一個引用到1端。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com