參考：http://www.cnblogs.com/WeiGe/p/4903850.html
一對多分為關聯模式和內嵌模式 內嵌與關聯什么時候用： 存在雙向查詢則用關聯，還需用到索引。 當兩者是包含關系，並且被包含的對象不會經常的變化，並不會進行雙向查詢，被包含對象不會進行其他的關聯查 則用到內嵌模式 注意，查詢頻率高的列應該加索引
一對很少 針對個人需要保存多個地址進行建模的場景下使用內嵌文檔是很合適，可以在person文檔中嵌入addresses數組文檔： 
這種設計具有內嵌文檔設計中所有的優缺點。最主要的優點就是不需要單獨執行一條語句去獲取內嵌的內容。最主要的缺點是你無法把這些內嵌文檔當做單獨的實體去訪問。 一對許多 以產品零件訂貨系統為例。每個商品有數百個可替換的零件，但是不會超過數千個。這個用例很適合使用間接引用---將零件的objectid作為數組存放在商品文檔中(在這個例子中的ObjectID我使用更加易讀的2字節，現實世界中他們可能是由12個字節組成的)。 每個零件都將有他們自己的文檔對象 
每個產品的文檔對象中parts數組中將會存放多個零件的ObjectID ： 
一對非常多 我們用一個收集各種機器日志的例子來討論一對非常多的問題。由於每個mongodb的文檔有16M的大小限制，所以即使你是存儲ObjectID也是不夠的。我們可以使用很經典的處理方法“父級引用”---用一個文檔存儲主機，在每個日志文檔中保存這個主機的ObjectID。
雙向關聯 如果你想讓你的設計更酷，你可以讓引用的“one”端和“many”端同時保存對方的引用。 以上一篇文章討論過的任務跟蹤系統為例。有person和task兩個集合，one-to-n的關系是從person端到task端。在需要獲取person所有的task這個場景下需要在person這個對象中保存有task的id數組，如下面代碼所示。 
在某些場景中這個應用需要顯示任務的列表（例如顯示一個多人協作項目中所有的任務），為了能夠快速的獲取某個用戶負責的項目可以在task對象中嵌入附加的person引用關系。 
這個方案具有所有的一對多方案的優缺點，但是通過添加附加的引用關系。在task文檔對象中添加額外的“owner”引用可以很快的找到某個task的所有者，但是如果想將一個task分配給其他person就需要更新引用中的person和task這兩個對象