8

假设您想对某些情况进行建模。公司可以有一个或多个分支机构。这些分支机构的员工可以在不同的公司（甚至同一公司的两个不同的分支机构）工作。这当然只是一个例子。

我们还假设大多数搜索/查询将在员工和公司集合上完成。

第一种（天真的）方法是嵌入所有内容（公司有分支机构，分支机构有员工）：

{
    name: "Company name",
    // other company data
    branches : [
        { 
            name: "Branch name",
            // other branch data
            Employees: [
                {
                    // employee1 data
                },
                {
                    // employee data
                },
            ]
        }
    ]
}

但是当人们对检索员工信息感兴趣时，这将是非常低效的（必须检索公司，然后遍历每个分支机构以查找所需的员工）。

另一方面，可以使用引用并模仿 RDBMS（会有 Company、Branch 和 Employee 集合），但这意味着更多的查询。

第三个选项（我最接近）是将 Employee 作为一个单独的集合，然后在 Branches 中有一个对它的引用数组。此外，为了允许更快的查询，例如：“具有特定名称的员工，为特定公司和特定分支机构工作”，Company ObjectId 可以存储在 Employee 集合中：

{
    company_id: "some id",
    first_name: "First name",
    last_name: "Last name",
    //
}

因此，在这种情况下，要搜索为特定公司和特定分支机构工作的具有特定姓名的所有员工，必须进行两次查询。第一个查询将返回满足“公司条件”（公司名称和分支机构名称）的公司，然后对 Employee 集合的第二个查询将返回所有具有指定名称且在其 id 在第一个查询中返回的公司工作的员工。

你会以其他方式做到这一点吗？有没有其他“推荐”的方式来做到这一点？你会添加一些改进吗？

更重要的是，当这两个查询返回的结果集有小的交集时怎么办？在这种情况下如何提高性能？

4

1 回答 1

5

我认为您大多朝着正确的方向前进。

虽然在某些情况下，MongoDB 中的非规范化并不像关系数据库中那样邪恶，但实际上是正确的做法，但这里有一个案例，您应该使用多个集合。这是因为 MongoDB 文档的上限为 16MB。当你有一家非常大的公司，有很多分支机构，有很多员工，并且员工子文档变得更加复杂时，你可以很容易地突破这个限制。

让员工向公司推荐是个好主意。但是你应该考虑不要使用公司的_id字段，而是使用公司名称和分公司名称，只要你能保证它们的每个组合在公司集合中都是唯一的（比如在这两个上使用唯一的复合索引字段）。原因是当您查找员工时，您通常还需要公司和分支机构的名称。当您只有 _id 时，您将不得不进行额外的查询以获取该信息。

你说你在分支机构和员工之间没有1：n的关系，而是一种：m的关系。在这种情况下，我建议您为每个员工添加一个“分配”数组，其中包含具有两个字段的对象，company_name 和 company_branch（也许您想添加第三个字段“职位”，说明他或她在做什么那里）。

您的员工文件将如下所示：

{
    first_name: "First name",
    last_name: "Last name",
    //
    assignments: [
        { company:"Aperture Science", branch:"R&D", position:"test subject" },
        { company:"Black Mesa", branch:"security", position:"leader of blue shift" }
    ]
}

请注意，您可以在这里使用无模式数据库的优势：您可以很容易地拥有不仅有分支机构，而且还有更多层次结构级别（如部门和组）的公司，而其他公司则没有。

但是当我想重命名公司或分支机构时怎么办？

In that case you would have to update each employee document which references the renamed company/branch. Yes, it wouldn't be the most efficient schema for that case. But remember that MongoDB schemas should always be optimized for the most common use-cases. What do you think will happen more frequently: a) a company or branch is renamed or b) someone wants to look up an employee?

于 2012-12-27T13:09:13.503 回答