{ author{ id, name, } } { author_id, author_name, }
有何優勢
首先需要知道，MongoDB是NoSQL中的一種，是不直接支援Join的，這是NoSQL的一個特點，不需要直接支援Join，可以將橫向擴展以及效能做到更好。
但是這不等於說MongoDB不能做Join所做的事情，為了達到傳統資料庫join的功能，MongoDB中有2個想法：
Embedding：透過Embedding子文檔，達到One to Many的關聯關係；這就是您說的嵌套結構；
Referencing：Referencing分為手工Referencing和自動Referencing；通常推薦是手工Referencing，通常是將需要關聯的文檔的Object_id保存在需要關聯的Collection中，也就是說需要關聯的Document的Object_id寫入時，分別寫入在兩個需要關聯的Collection裡面。
上述兩個思路，也正是MongoDB的Data Model的主要思路。
那麼上述2個思路在具體的運用的時候，怎麼區分開呢？
如果能夠Embedding的Sub Document，不需要單獨被查詢，那就直接Embedding；
如果這個Sub Document需要對外提供查詢，則單獨保存為一個Collection，並使用Referencing與其他collecion關聯。
供參考。
Love MongoDB！ Have Fun！
不見不散，19日，請戳：>---
MongoDB線上講座系列19- MongoDB 10步驟建構單一視圖
文檔型結構，更貼近我們對物件屬性的描述；透過一筆記錄就可以描述出一個物件的所有屬性，這就是一個優勢！
首先需要知道，MongoDB是NoSQL中的一種，是不直接支援Join的，這是NoSQL的一個特點，不需要直接支援Join，可以將橫向擴展以及效能做到更好。
但是這不等於說MongoDB不能做Join所做的事情，為了達到傳統資料庫join的功能，MongoDB中有2個想法：
Embedding：透過Embedding子文檔，達到One to Many的關聯關係；這就是您說的嵌套結構；
Referencing：Referencing分為手工Referencing和自動Referencing；通常推薦是手工Referencing，通常是將需要關聯的文檔的Object_id保存在需要關聯的Collection中，也就是說需要關聯的Document的Object_id寫入時，分別寫入在兩個需要關聯的Collection裡面。
上述兩個思路，也正是MongoDB的Data Model的主要思路。
那麼上述2個思路在具體的運用的時候，怎麼區分開呢？
如果能夠Embedding的Sub Document，不需要單獨被查詢，那就直接Embedding；
如果這個Sub Document需要對外提供查詢，則單獨保存為一個Collection，並使用Referencing與其他collecion關聯。
供參考。
Love MongoDB！ Have Fun！
不見不散，19日，請戳：>---
MongoDB線上講座系列19- MongoDB 10步驟建構單一視圖
文檔型結構，更貼近我們對物件屬性的描述；透過一筆記錄就可以描述出一個物件的所有屬性，這就是一個優勢！