MongoDB的Schema設計場景關係說明
文:Johnson Wu
MongoDB是著名的NoSQL資料庫，不同以往的RDBMS的ROW-COLUMN格式每個物件的欄位不一定相同，且在NoSQL資料庫較可以動態擴充欄位。
但更高的彈性也意味著需要有更好的設計規劃，為了讓資料更好被維護，應該需要針對業務邏輯規劃Schema。
有很多剛從RDBMS轉換到MongoDB的初學者只是把在只是把在RDBMS的作法照搬一份到MongoDB將Collection當Table在使用，反而會質疑為何要轉換MongoDB?
也沒有獲得太多MongoDB帶來的好處，且有可能造成存取上的負擔。
設計場景
初探MongoDB時遇到幾個問題個問題，何時應該進行正規化？
相關資料如何進行關聯？
如何跨Collection進行存取？
如何處理ACID相關問題？
MongoDB支援JSON格式儲存，因此單一Document可以直接存入多層格式的物件，但單一Document還是有最大16MB、最大深度100的上限限制。
在這兩個條件下，我們以資料基數將基本的設計模式分為：
- One-to-Few (少量)
- One-to-Many (多量)
- One-to-Squillions (海量)
One-to-Few
當預主體的欄位所包含的資料是有限且可預期的，且符合Document的限制(16MB)，就可以使用One-to-Few的模式，這樣的方式稱為Embedding。
優點：在於不需再執行額外的查詢來獲取詳細的資訊
缺點：則是無法將嵌入的資訊當作個體（stand-alone entities）單獨查詢
One-to-Many
當預期主體的欄位資料數量雖然可預期，但Embedding物件全部都放在同一個Document可能會超過16MB的上限，且若考慮資料獨立性問題，就可以參考RDBMS的關聯做法，將關聯的資料放在另一個Collection，並在Parent Document紀錄關聯的ObjectId，實際查詢時透過Application-Level Join進行反查。此種方法可滿足多量級的一對多關係，並保有資料獨立性，這種方式稱為Child-Referencing。
優點：優點在於每個關聯物件都是獨立的Document，因此很容易對關聯的Document進行查詢及更新
缺點：需要執行至少兩次查詢才能取得完整資訊
One-to-Squillions
當預期主體參照的另一個主體可能為海量級(資料會無限增長)，不論是儲存多個物件或是多個ObjectId，都無法保證在單一Document最大16MB的限制。當遇到這個情況時可以換成反向參考，在海量級主體中紀錄主體的ObjectId，此種方式稱為Parent-Referencing。
優點：適合存放資料量會隨著時間成長，例如系統日誌、交易日誌等等
缺點：需要執行至少兩次查詢才能取得完整資訊
專人協助
由偉康業務人員為您詳細說明偉康的解決方案，以及相關產業經驗。
訂閱偉康科技洞察室部落格，掌握最新科技趨勢！
About The Author
