1

案例:系统中有用户,并且有静态文档(如书籍)每个用户可能会使用一些文档,并且对于他的每个文档都有特定的状态/设置(如文档中的当前位置/页面、书签/注释)。

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

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

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

第一种情况的优点:

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

第一种情况的缺点:

1) 更多的文件

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

第二种情况的优点:

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

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

第二个缺点:

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

需要考虑的一些事项:

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

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

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

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

4

1 回答 1

2

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

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

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

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

于 2013-02-15T09:53:19.640 回答