用于存储子关系的MongoDB体系结构最佳实践？

假设我需要将经理/员工关系存储在mongoDB数据库中，并且为了举例说明可以说这些是两个不同的集合。我一般尽量通过构造文件/ DB这样来显示这种关系：用于存储子关系的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中存储像这样的子关系的最佳实践吗？

来源

2017-04-07 Abe Miessler

第一种方法中的同样缺点，如果管理器被删除。如果您使用任何类型的ODM（更新整个文档），则第二种方法可能不太方便。使用并发更新时，可能会丢失employees数组中的一些元素。没有$ push/$ pull更新的问题。另外第一种方法对于$ lookup聚合更简单。如果一个人有很多管理者，第二种方法似乎很好。作为一个经验法则，模式应该支持查询，而不仅仅反映关系，这与SQL方法略有不同。 –

关于模式应该支持查询的真正好点不仅仅是反映关系。 –

MongoDB博客文章6 Rules of Thumb for MongoDB Schema Design对这个主题有很好的讨论，并且权衡了很多优点和缺点。

还搜索“mongodb嵌入与链接”，你会得到很多的参考和意见。

来源

2017-04-07 23:14:41 helmy

有一本关于mongoDB最佳实践的好书。你可以阅读这本书，并得到最好的想法。

书名：50提示和技巧MongoDB的开发通过 克里斯蒂娜·乔多罗

为注释，选择方法＃2是密切相关的员工数组的大小，你多久修改这个字段？如何在员工中搜索？和更多的过滤器。

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

来源

2017-04-08 07:17:34 Saeed

用于存储子关系的MongoDB体系结构最佳实践？

回答

相关问题