1. 程式人生 > >[NoSQL] 從模型關係看 Mongodb 的選擇理由

[NoSQL] 從模型關係看 Mongodb 的選擇理由

 

往期:Mongodb攻略

 

回顧 Mongodb 與關係型資料庫的對應關係:

  MySQL         MongoDB

  database(資料庫)   database(資料庫)

  table(表)       collection(集合)

  rows(記錄)      document(文件物件)

 

建模時的決定直接影響到應用程式的效能和資料的處理能力。

 

內嵌式資料模型和規範化資料模型的選擇。

一般來說,下述情況建議使用內嵌資料:

  • 資料物件之間有 “contains” (包含) 關係。 參見 一對一關係建模:內嵌文件模型。

  • 資料物件之間有一對多的關係。 這些情況下 “多個”或者子文件會經常和父文件一起被顯示和檢視。請參見 一對多關係建模: 內嵌文件模型。

通常情況下,內嵌資料會對讀操作有比較好的效能提高,也可以使應用程式在一個單個操作就可以完成對資料的讀取。 同時,內嵌資料也對更新相關資料提供了一個原子性寫操作。

當需要訪問內嵌的資料時,你可以使用 dot notation 。 欲瞭解如何訪問陣列內資料或內嵌文件資料,參見 陣列內資料查詢 以及 內嵌文件資料查詢 。

 

一般來說,在下述情況下可以使用規範化模型:

  • 當內嵌資料會導致很多資料的重複,並且讀效能的優勢又不足於蓋過資料重複的弊端時候。

  • 需要表達比較複雜的多對多關係的時候。

  • 大型多層次結構資料集。

 關於引用的例子,參見 一對多關係建模: 文件引用模式 。關於使用引用的樹結構模型的例子,參見 樹結構建模。

 

引用比內嵌要更加靈活一些。 但客戶端應用必須使用二次查詢來解析文件內包含的引用。換句話說,對同樣的操作來說,規範化模式會導致更多的網路請求傳送到資料庫伺服器端。 

 

經驗:MongoDB資料庫設計中6條重要的經驗法則。

 

小結:

你可以看出,Mongodb 的明顯特色是內嵌、無Schema進行儲存。那麼在多對多關係場景下,SQL 支援原子操作、更適應查詢,其它情況下可以考慮用 Mongodb 優化掉二次查詢。

這是從模型關係來看 SQL 與 NoSQL 誰更適合,當然 Mongodb 自身其它特性一定更特近不同應用的場景。

 

EnDoc:https://docs.mongodb.com/manual/tutorial/model-referenced-one-to-many-relationships-between-documents/

CnDoc:http://www.mongoing.com/docs/tutorial/model-referenced-one-to-many-relationships-between-documents.html

Link:https://www.cnblogs.com/farwish/p/12131313.html