Mongodb模式存儲用戶/項目特定數據

Question

案例： 系統中有用戶，並且有靜態文檔（如書本）每個用戶可以使用某些文檔並具有特定狀態/設置（如當前位置/頁面在文件，書籤/筆記）爲他的每個文檔。

什麼是更好的方式來存儲該用戶和文檔的具體信息在兩個鍵userId和documentId或集合的_id等於userId和_id等於documentId的子文檔的嵌套數組（在該場景集合也用於存儲非文檔特定的用戶數據）？

1 scenaroio：發現（{用戶名：...，documentId：...}）

第二scenaroio：findBy（{_ ID：...}），然後找到_id相等的子文檔到documentId第1方案的

優點：

1）我相信，更快找到並保存操作。第一個場景的

缺點：

1）的文件

2）沒有辦法來存儲一些非文檔中收集有關用戶特定的數據量更大

第二種情景的優先級：

1）bette r表示數據關係（主觀雖然）

2）使得使用相同的集合來存儲一些其他非特定文檔相關的用戶數據成爲可能。 2日

缺點：

1）更加難以搜索和更難以保存操作（我使用的貓鼬ODM和代碼不會是複雜的），我覺得操作不太迅速然後在第一種情況下。

有些事情要考慮：

1）一般在讀取操作我將只選擇一個文件的具體數據

2）我需要經常保存一個文件的具體數據（例如定期在用戶正在處理的文檔中保存位置）。

3）用戶/文檔狀態可具有一些嵌套數組必須被改變（文件插入/移除（書籤，註釋））

採取這種考慮我會說，第一方案是更適合任務，但我想聽聽一些專業意見，兩種情況是否有很大差異。

Answer 1

什麼是您的實際訪問路徑？你是從一個用戶標識開始，並查找用戶閱讀的文檔？或者你是從文檔開始搜索用戶，並閱讀它？ 文檔對象是輕量級的（只是標題和作者等信息）還是重量級（包括內容）？ 如果文件重量很大，我會將它們放在一個單獨的集合中，並用於場景2.

基本上，場景1模仿關係解決方案，場景看起來像對象模型。

我相信對象模型更好地描述現實，並且更高效。

所以我會去情景2，除非你經常搜索讀者的書。