MongoDB嵌入與SQL外鍵？

Question

與SQL爲相同邏輯使用外鍵相比，MongoDB在文檔中嵌入對象的能力有什麼特別的優勢嗎？

在我看來，唯一的優勢是易用性（也許性能？），甚至看起來它可以很容易地被抽象掉（例如，Django似乎很直觀地處理SQL的外鍵）。

Answer 1

這歸結爲是否嵌入的經典問題。

這裏有上手幾個環節之前，我解釋多一些：

• Where should I put activities timeline in mongodb, embedded in user or separately?
• MongoDB schema design -- Choose two collection approach or embedded document
• MongoDB schema for storing user location history

現在更具體地回答。

您必須記住SQL：JOIN中的外鍵的服務器端用法。嵌入是一次往返以獲取單個文檔中所需的所有數據，但連接不是，它們實際上是基於範圍的兩個選擇，然後合併以省略重複（對於某些數據集有大量開銷）。

因此，外鍵的使用並不完全取決於應用程序，它也取決於服務器和數據庫。

這就是說有人誤解在MongoDB中嵌入並嘗試將所有數據放入一個文檔中。不幸的是，這是通過您應該總是試圖嵌入一切的常識來重新強化的。鏈接和更多將提供一些有用的指導。

現在我們清理一些東西嵌入在加入的主要優點是：

• 單次往返
• 輕鬆更新文檔中的很多情況下，除非您嵌入深
多層次
• 能保持實體數據與它關係到

然而，實體嵌入有幾個缺陷：

• 的文件必須在分頁得到它的價值觀，這可以在較大的文檔
• 子文檔被設計成獨特的，不需要高級查詢，所以你通常不會得到兩個獨立的實體的實體問題的是，相關在一起，即post可能會嵌入comments，但由於查詢需要，user可能不會嵌入posts。
• 嵌套深度超過3級可能會影響您使用諸如原子鎖等事物的能力。

所以，當使用正確的MongoDBs嵌入可以成爲SQL聯接的巨大力量，但你必須明白何時使用它的權利。

Answer 2

Mongo的核心優勢在於其數據文檔視圖，當然這可以擴展到數據的「POCO」視圖。像.NET中的NoRM Project這樣的Mongo客戶端與經驗豐富的Fluent NHibernate用戶看起來非常相似，這並非偶然 - 您的POCO數據模型簡單地序列化爲BSON並保存在Mongo 1：1中。無需映射。

總體而言，這兩種技術最大的區別在於模型以及開發人員如何思考他們的數據。 Mongo更適合於快速應用程序開發。