面向文檔的數據庫是否比關係數據庫更適合持久化對象？

Question

就數據庫的使用而言，過去十年是ORM的時代，數百個競爭者將我們的對象圖保存在普通的老式RMDBS中。現在我們似乎正在見證面向文檔的數據庫時代的到來。 Thesedatabases針對無模式文檔進行了高度優化，但對於並行擴展和查詢集羣的能力也非常有吸引力。

面向對象的數據庫在面向對象的設計中也具有優於RDBMS的優點。由於這些表是無模式的，因此可以將屬於不同類的對象並排存儲在繼承層次結構中。此外，隨着領域模型的變化，只要代碼能夠應對從舊版本的領域類獲取對象，就可以避免在每次更改時遷移整個數據庫。

另一方面，面向文檔的數據庫的性能優勢主要表現在存儲更深的文檔時。在面向對象的術語中，由其他類組成的類，例如博客文章及其評論。在大多數我可以想到的例子中，比如博客，讀取訪問的好處似乎被每次發表新評論時必須撰寫整篇博客帖子「文檔」的懲罰所抵消添加。

在我看來，面向對象的數據庫可以爲面向對象的系統帶來顯着的好處，如果需要極其謹慎地組織深度圖中的對象，以優化數據的讀寫方式，但這意味着知道最前面的用例。在現實世界中，我們通常不知道，直到我們實際上有一個我們可以描述的實時實現。

那麼關係型和文檔型數據庫的情況就是波動和環島？我對人們的意見和建議感興趣，特別是如果任何人在面向文檔的數據庫上構建任何重要的應用程序。

Answer 1

那麼它取決於你的數據結構和數據訪問模式。

文檔數據庫存儲和檢索文檔和基本原子存儲單元是一個文檔。正如你所說的，你需要考慮你的數據訪問模式/用例來創建一個智能文檔模型。當您的域模型可以在一些文檔中拆分和分區時，文檔數據庫就像魅力一樣。例如，對於博客軟件，CMS或維基軟件來說，document-db工作得非常好。只要您能找到一種將數據擠入文檔的好方法，就不會有任何問題。但不要嘗試to fit a relational-model into a document-database。 只要你的數據訪問模式在關係上使用了大量的「導航」，圖形或對象數據庫是更自然的選擇。

另一件事是關於讀/寫性能的權衡。例如博客軟件。在過渡RDBMS數據模型中，數據被標準化。這意味着，閱讀數據是昂貴的，因爲從不同的表中讀取，計算與連接等的關係來閱讀博客文章。作爲交換，更換標籤便宜。 相反，在閱讀博客文章的文檔數據庫中很便宜，因爲您只需加載後期文檔。但是更新可能會更昂貴，因爲您需要存儲整個文檔。或者更糟糕的是，通過大量文檔來改變某些內容（重命名標籤場景）。在大多數系統中，閱讀比寫作更重要。所以使用重新規格化的數據存儲實際上是有意義的。

我認爲在大型數據庫中，無模式設計可以有其優點。在RDBMS中，你需要升級你的模式，這是一個非常痛苦的過程。特別是將現有數據轉換爲新的模式。在無模式數據庫中，您的應用程序需要處理這個問題，從而提供更大的靈活性。例如，您可以在訪問舊文檔時即時升級架構。這樣，您可以保持您的巨型數據庫正常運行，而應用程序可以即時處理舊版本。