MongoDB架构最佳实践：如何存储子关系？

Question

假设我需要将管理者和员工的关系存储在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中存储此类子关系的最佳实践？

- Abe Miessler

---

第一种方法存在同步的缺点，如果删除了一个经理。如果您使用任何类型的ODM更新整个文档，则第二种方法可能不太方便。在并发更新过程中，您可能会丢失employees数组中的一些元素。但是对于$push/$pull更新不是问题。另外，第一种方法更简单适用于$lookup聚合。如果一个人有很多经理，第二种方法似乎很好。粗略来说，模式应支持查询，而不仅仅是反映关系，这与SQL方法略有不同。 - Alex Blex

关于模式应该支持查询而不仅仅是反映关系的观点非常好。 - Abe Miessler

Answer 1

这篇MongoDB博客文章 《MongoDB模式设计六个经验法则》 对此主题进行了深入讨论，并权衡了许多利弊。

另外搜索“mongodb嵌入 vs 链接”，你将找到许多相关参考和意见。

- helmy

Answer 2

有一本关于MongoDB最佳实践的好书。您可以阅读此书并获得最佳想法。

书名：50个面向MongoDB开发人员的技巧和技巧 作者：Kristina Chodorow

作为评论，选择方法#2与员工数组的大小、您多频繁修改此字段、在员工中搜索以及更多筛选相关。

我建议使用方法#1，每个员工都有对其直接上级的引用，数据类型更简单。 String / Object vs Array

- Saeed