存储子关系的MongoDB架构最佳实践？答案

【问题标题】：MongoDB architecture best practices for storing child relationships?存储子关系的MongoDB架构最佳实践？
【发布时间】：2017-09-03 00:26:25
【问题描述】：

假设我需要在 mongoDB 数据库中存储经理/员工关系，并且为了举例，假设这是两个不同的集合。我通常尝试通过像这样构造文档/数据库来显示这种关系：

经理收集文件：

{
   id: 1,
   name: "Bill Smith"
}

员工收款文件：

{
  id: 1,
  name: "Abe Smith",
  managerId: 1
},
{
  id: 2,
  name: "Hank Smith",
  managerId: 1
}

但我经常看到人们以这种方式存储这种关系：

方法#2

经理收集文件：

{
  id: 1,
  name: "Bill Smith",
  employees: [1, 2]
}

员工收款文件：

{
  id: 1,
  name: "Abe Smith"
},
{
  id: 2,
  name: "Hank Smith"
}

我在第二种方法中看到的缺点是，如果从集合而不是数组中删除员工，employees 数组可能会不同步。

我很好奇是否有人可以指出这两种不同方法的优缺点，以及是否一种通常被认为是在 MongoDB 中存储此类子关系的最佳实践？

【问题讨论】：

如果删除管理器，第一种方法中的同步缺点相同。如果您使用任何一种更新整个文档的 ODM，第二种方法可能不太方便。通过并发更新，您可能会丢失员工数组中的一些元素。 $push/$pull 更新不是问题。对于 $lookup 聚合，第一种方法也更简单。如果一个人有很多经理，第二种方法似乎很好。根据经验，schema 应该支持查询，而不仅仅是反映关系，这与 SQL 方法略有不同。
关于架构应该支持查询而不仅仅是反映关系，这一点非常好。

【解决方案1】：

MongoDB 博文6 Rules of Thumb for MongoDB Schema Design 对这个主题进行了很好的讨论，并权衡了许多利弊。

同时搜索“mongodb embedding vs linking”，你会得到很多参考和意见。

【讨论】：

【解决方案2】：

有一本关于 mongoDB 最佳实践的好书。您可以阅读本书并获得最佳创意。

书名：给 MongoDB 开发人员的 50 个技巧和窍门 克里斯蒂娜·乔多罗

作为评论，选择方法#2 与员工数组的大小密切相关，您多久修改一次此字段？在员工中搜索怎么样？和更多过滤器。

我推荐方法#1，每个员工都可以使用更简单的数据类型直接引用他/她的经理。字符串/对象与数组

【讨论】：