用于存储用户/项目特定数据的 Mongodb 模型

Question

案例： 系统中有用户，并且有静态文档（如书籍）每个用户可能会使用一些文档，并为他的每个文档具有特定的状态/设置（如文档中的当前位置/页面、书签/注释）。

将用户和文档特定信息存储在具有两个键 userId 和 documentId 的平面集合中的更好方法是什么，或者 _id 等于 userId 的集合和 _id 等于 documentId 的子文档的嵌套数组（在这种情况下，集合是也用于存储非文档特定的用户数据）？

第一个场景：find({userId: ..., documentId:...})

第二个场景：findBy({_id:...})，然后找到_id等于documentId的子文档

第一种情况的优点：

1) 我相信更快的查找和保存操作。

第一种情况的缺点：

1) 更多的文档

2) 无法在集合中存储一些与文档无关的用户特定数据

第二种情况的优点：

1) 更好地表示数据关系（虽然是主观的）

2) 可以使用同一个集合来存储一些其他非特定文档相关的用户数据。

第二个缺点：

1) 更难的搜索和更难的保存操作（我使用的是 Mongoose ODM，代码不会很复杂），而且我认为操作速度不如第一种情况。

需要考虑的一些事项：

1) 通常在读取操作中我会只选择一个文档特定数据

2) 我需要经常保存一个文档的特定数据（例如定期保存用户正在使用的文档中的位置）。

3) 用户/文档状态可能有一些嵌套数组（书签、注释）需要更改（插入/删除文档）

考虑到这一点，我会说第一种情况更适合该任务，但我想听听一些专业人士的意见，两种情况是否有很大差异。

Answer 1

您的实际访问路径是什么？您是否从用户 ID 开始，然后查找用户阅读的文档？还是从文档开始并搜索阅读它的用户？ 文档对象是轻量级的（只是标题和作者等信息）还是重量级的（包括内容）？ 如果文档是重量级的，我会将它们保存在一个单独的集合中并转到场景 2。

场景 1 基本上模拟了一个关系解决方案，场景看起来像一个对象模型。

我相信对象模型能更好地描述现实并且更有效。

所以我会选择方案 2，除非你经常在读者中搜索一本书。