【问题标题】:Have embedded documents instead of relying on foreign keys?有嵌入文档而不是依赖外键?
【发布时间】:2019-11-28 01:26:04
【问题描述】:

我是 MongoDB 和 NoSQL 的新手。我实际上有不同的后续问题,具体取决于如何回答这个问题。我会将我的后续问题作为一个单独的问题发布。我们来了...

我正在尝试为数据库建模以帮助我回答一个问题,例如“查找所有部门,其中 2 (TWO) 或更多团队每个有 2 (TWO) 或更多员工已知造成的事故大于其团队的 max_accidents。 "如果允许我在 MySQL 中使用关系数据库,我会通过制作这些表来解决问题:

department:department_id, location_id (FK to a location table not described here), unit_type

team: team_id, department_id, max_accidents

employee: employee_id, team_id, accidents

然后我会使用这个查询(未经测试,但希望你明白):

SELECT department_id FROM team
WHERE EXISTS (

    SELECT 1 FROM department
    WHERE department.department_id = team.team_id
    AND team.team_id IN (

        SELECT team_id FROM employee
        WHERE EXISTS (
            SELECT 1 FROM team
            WHERE team.team_id = employee.team_id
            AND employee.accidents > team.max_accidents
        ) GROUP BY team_id HAVING COUNT(*) >=2

    )
) GROUP BY department_id HAVING COUNT(*) >= 2

根据我对 NoSQL 数据库的了解,我可以看到两种方法来为我的集合建模。首先,我可以以与我在上面列出表格的方式完全相同的方式对每个集合进行建模,这意味着外键将存在。第二种可能的方式是这样的:

department = {_id,teams:[]team};

team = {_id,max_accidents,employees:[]employee};

employee = {_id,accidents};

我的猜测是我应该使用嵌入文档数组的第二种方法。然后要执行我的查询,我需要学习如何使用 MongoDB 聚合框架,如下面的问题所示:

Compare embedded document to parent field with mongoDB

我可以通过使用$match 功能在聚合方法的基础上实现我的HAVING COUNT(*) 行为,如下面的问题所示:

What is the correct way to do a HAVING in a MongoDB GROUP BY?

我想确认我是否正确地解决了这个问题?如果没有,如果有人能解释为什么我可能会以错误的方式接近它,或者我可能需要关注什么,那就太好了。

【问题讨论】:

    标签: mongodb nosql


    【解决方案1】:

    来自 MongoDB 文档

    一般来说,在以下情况下使用嵌入式数据模型:

    • 实体之间存在“包含”关系。见型号 与嵌入式文档的一对一关系。
    • 你有一对多 实体之间的关系。在这些关系中,“许多”或 子文档总是与 “一个”或父文件。请参阅模型一对多关系 嵌入式文档。

    一般来说,嵌入提供更好的性能 用于读取操作,以及请求和检索的能力 单个数据库操作中的相关数据。嵌入式数据模型使 可以在单个原子写入操作中更新相关数据。

    这是一个足够公平的准则。但是,您可以根据您的情况接听电话。

    提问:

    • 一个员工可以加入多个团队吗?
    • 一个团队可以是多个部门的一部分吗?

    如果答案是肯定的,就不会考虑嵌入文档。

    假设一名员工属于多个团队的情况。这意味着员工对象存在于多个文档中。

    这可能导致:数据重复、需要更多存储空间、使更新变得多余。

    【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-10-02
    • 1970-01-01
    • 1970-01-01
    • 2013-08-21
    • 1970-01-01
    相关资源
    最近更新 更多