在 MongoDB 中，为经常查询的对象提供自己的引用模式是更好的做法，还是将它们留在父级中？

Posted 2023-03-11

【中文标题】在 MongoDB 中，为经常查询的对象提供自己的引用模式是更好的做法，还是将它们留在父级中？

【英文标题】：In MongoDB, is it better practice to give commonly queried objects their own referenced Schemas, or leave them in their parent?

【发布时间】：2014-03-11 11:58:21

【问题描述】：

我是 Mongo 的新手，虽然这似乎是一件很常见的事情，但我在文档中找不到明确的“最佳”解决方案。这是我的设置：

我正在构建一个共享待办事项列表应用程序，该应用程序允许用户将其他用户添加到他们的待办事项中。我正在使用 3 个主要模式进行设置：

用户（个人资料数据和登录信息）， TodoList（订阅了TodoItems 的数组和Users 的数组）

TodoItem（元数据和 cmets）

var User = new mongoose.Schema(
    username:  type:String, required:true , unique:true,
    password: type:String, required:true,
    memberOfAccounts: [type: mongoose.Schema.Types.ObjectId, ref: "Account"]
);

var TodoList = new mongoose.Schema(
    todos: [type: mongoose.Schema.Types.ObjectId, ref: "TodoItem"],
    subscribers: [type: mongoose.Schema.Types.ObjectId, ref: "User"],
    title: type: String
);

var TodoItem = new mongoose.Schema(
    parentList:Id type: mongoose.Schema.Types.ObjectId, ref: "TodoList",
    text: [type: String],
    completed: type: Boolean,
    comments: [
        text: type: String,
        author: type: mongoose.Schema.Types.ObjectId, ref: "User"
    ]
);

一个User 可以订阅多个TodoListss（多对多），而一个TodoItem 只能存在于一个TodoList 中。此外，TodoItem 的 cmets 应单独查询，TodoItem 的任何其他属性也应单独查询。

最终我希望TodoItem 更复杂（开始日期、结束日期、分机时间等），这也将使它成为最活跃的文档，这就是我给它自己的模型的原因首先。我意识到这可能不是构建它的最佳方式，因为它仍然是一对多关系，也许新的TodoItemss 应该直接推送到TodoList 中的“todos”数组文件。

tl;dr: 我应该创建深度嵌套的模式，其中最常查询/写入的对象是子对象，还是应该创建单独的集合以通过对父对象中的这些对象的引用进行查询？

【问题讨论】：

我在输入此内容时意识到，在包含大量 TodoItem 的数据库中，在整个列表中搜索与请求的 parentListId 匹配的项目需要更长的时间，但我没有有任何依据。

Embedded document vs reference in mongoose design model?的可能重复

我不会将其标记为重复，因为我不确定该问题的内容是诚实的（关于该主题的许多问题具有更好的内容），相反我只会提到 OP应该谷歌吗

【参考方案1】：

通常查询的对象更适合作为父文档。根据嵌套的范围/复杂性，索引的效率会降低，因为要遍历的内容更多。

元数据、修订和历史数据可以驻留在子文档中。