MongoDB - 多對多關系？

Question

我很好奇如何構建一個擁有多對多關系的MongoDB，可能有數萬條記錄。

假設您有一個餐館數據庫，可以跟蹤大量的餐館和所有已經入住這些餐館的人。 因此，用戶可能想要查找一個人並查看他們檢查過的所有餐館，還可以查找餐館並查看已登記的所有人。

如何以一種有意義且易於搜索和更新的方式構建它？

Answer 1

您提供的示例與大多數真實世界的多對多關系示例一樣，實際上是少數關系的一個示例。 您可能有許多餐館和許多用餐者，但與整套餐廳相比，任何一家餐廳只供應一小部分食客，大多數個人用餐者只會訪問一小部分餐館。 這聽起來像一個稀疏鏈接的網絡，其鏈路密度比明顯低於1。

為了測量網絡的鏈路密度（邊緣密度），我們計算現有鏈路m與可能鏈路總數的比率。 對於N個節點的網絡，網絡鏈路密度為D = m / 0.5 * N *（N-1）完全連接網絡的（最大）鏈路密度D為1. - 網絡 - 科學

但是，您詢問了多對多，那么我們如何以神經網絡為例呢？ 神經網絡通常形成密集網絡，因此代表真正的多對多網絡。 在這種情況下答案很簡單 - 不要使用mongoDB。 使用根據您的特定要求定制的自定義結構和序列化策略。 畢竟，真正的多對多關系幾乎總是異常，因此可以證明具體的治療方法是正確的。

話雖如此，可以在不犧牲豐富的文檔結構的情況下實現對mongoDB中更常見的少數關系的建模，以及如何實現這一點取決於您的訪問模式。

因此，通過餐廳/餐館網絡示例，如果您通常要在其食客上查詢餐館，那么您將創建一個與每個餐廳一起保存的diner_ids數組。 另一種方式意味着每個用餐者都會舉辦一系列restaurant_ids。 兩者都用於雙向查詢能力。

必須小心，因為mongoDB中沒有foreign_key約束，因此維護數據的引用完整性是您的責任。

如果性能對您來說最重要，那么您可能希望將數據嵌入到每個文檔中，而不是使用id引用它。 這是用於讀取的更高性能選項（不是用於寫入），因為所有數據都可以在一次命中中從磁盤中拉出。 這意味着在更新數據值時需要做更多工作以確保數據的完整性，但通常這並不像它最初看起來那么可怕。 用餐者經常改變名字的頻率是多少？ 根據文檔大小的不同，您可能不一定要嵌入完整的文檔，數據的子集加上指向完整記錄的id通常會起作用。

簡而言之，mongoDB架構設計應該由應用程序要求驅動。 不同應用程序的不同模式，而不是一個單片關系數據庫來統治它們。 數據的實際情況是什么？ 應用程序如何實際使用此數據？ 文件對象的存儲量有多大？ 回答這些問題，您的架構將實際設計自己。

Answer 2

我會創建一個checkins或visits集合。 當用戶訪問該餐館時，創建一個引用用戶和餐館的新文檔。 這是相當干凈和直接的