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

本案： 系统中有用户，也有静态文档（如书籍），每个用户可以处理一些文档，并对其每个文档具有特定的状态/设置（如文档中的当前位置/页面、书签/注释）

使用两个键userId和documentId在平面集合中存储用户和文档特定的信息，或者使用_id等于userId的集合和_id等于documentId的子文档嵌套数组（在该场景中，集合还用于存储非文档特定的用户数据），更好的方法是什么

第一个场景：查找（{userId:…，documentId:…}）

第二个场景：通过（{u id:…}）查找，然后查找{u id等于documentId的子文档

第一种方案的优点：

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

第一种情况的缺点：

1） 大量文件

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

第二种情况的优点：

1） 更好地表示数据关系（尽管主观）

2） 使使用同一集合存储其他一些与文档无关的用户数据成为可能

第2条的反对意见：

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

需要考虑的一些事项：

1） 通常，在读取操作中，我只需要选择一个特定于文档的数据

2） 我通常需要保存一个文档特定的数据（例如，定期保存用户正在处理的文档中的位置）

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

---

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

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

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

我相信对象模型能更好地描述现实，而且效率更高

---

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

一般来说，不要担心写性能。优化您的查询。@Esteban Araya谢谢，但“优化查询”是什么意思？对于第一个或第二个场景，您是否有任何偏好，您会选择哪一个？文档状态不重，常见的场景我需要一次获取一个（一个用户一个文档状态）。我不需要经常为某个特定文档获取用户，至少它肯定不是应用程序的实时场景。我经常需要做的是保存特定文档的状态。