有嵌入的文档而不是依赖外键吗? [英] Have embedded documents instead of relying on foreign keys?
问题描述
我是 MongoDB 和 NoSQL 的新手.我实际上有不同的后续问题，具体取决于如何回答这个问题.我会将我的后续问题作为一个单独的问题发布.来了……
I am new to MongoDB and NoSQL. I actually have different follow up questions depending on how this question gets answered. And I'll post my follow up questions as a separate question. Here we go...
我正在尝试对数据库进行建模以帮助我回答诸如查找所有部门，其中 2 (TWO) 或更多团队每个部门有 2 (TWO) 或更多员工已知造成的事故超过其团队的 max_accidents."如果允许我在 MySQL 中使用关系数据库，我会通过制作这些表来解决问题:
I am trying to model a database to help me answer a question such as "Find all departments where 2 (TWO) or more teams each have 2 (TWO) or more employees known to have caused accidents greater than their team's max_accidents." If I were allowed to use a relational database with MySQL, I would solve the problem by making these tables:
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
然后我会使用这个查询(未经测试，但希望你能理解):
And then I'd use this query (untested, but hopefully you get the idea):
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 数据库的了解，我可以看到两种对我的集合进行建模的方法.首先，我可以以与我在上面列出的表格完全相同的方式对每个集合进行建模，这意味着外键将存在.第二种可能的方法是:
From what I understand about NoSQL databases, I can see two ways to model my collections. First, I could model each collection in exactly the same way I set out my tables above, meaning foreign keys would exist. The second possible way is this:
department = {_id,teams:[]team};
team = {_id,max_accidents,employees:[]employee};
employee = {_id,accidents};
我的猜测是我应该使用第二种方法来嵌入文档数组.然后要执行我的查询，我需要学习如何使用 MongoDB 聚合框架，如这里问题所示:
My guess is that I should use the second approach where I embed arrays of documents. Then to perform my query, I would need to learn how to use the MongoDB aggregate framework as demonstrated in this question here:
我可以在聚合方法的基础上使用 $match 功能来实现我的 HAVING COUNT(*) 行为，如下面的问题所示:
I can build upon the aggregate approach to implement my HAVING COUNT(*) behaviour by using the $match feature as demonstrated in this question here:
什么在 MongoDB GROUP BY 中执行 HAVING 的正确方法是什么?
我想确认一下我是否正确地解决了这个问题?如果没有，如果有人能解释为什么我可能会以错误的方式接近它或我可能需要关注什么，那就太好了.
I'd like confirmation if I'm approaching this problem correctly? If not, would be great if someone could explain why I might be approaching it the wrong way or what I might need to concern myself with.
推荐答案
来自 MongoDB 文档
From MongoDB Documentation
通常，在以下情况下使用嵌入式数据模型:
In general, use embedded data models when:
- 实体之间存在包含"关系.查看型号与嵌入式文档的一对一关系.
- 你有一对多实体之间的关系.在这些关系中，许多"或子文档始终与上下文一起出现或在上下文中查看一个"或父文件.请参阅模型一对多关系嵌入式文档.
总的来说，嵌入提供更好的性能用于读取操作，以及请求和检索的能力单个数据库操作中的相关数据.嵌入式数据模型使可以在单个原子写操作中更新相关数据.
In general, embedding provides better performance for read operations, as well as the ability to request and retrieve related data in a single database operation. Embedded data models make it possible to update related data in a single atomic write operation.
这是一个足够公平的指南.但是，您可以根据您的情况接听电话.
This is a fair enough guideline. However you can take you call depending on your case.
提出问题:
- 一名员工可以加入多个团队吗?
- 一个团队可以隶属于多个部门吗?
如果答案是肯定的，就不会考虑嵌入文件.
If answer is yes, would not think about embedded documents.
考虑一个员工隶属于多个团队的场景.这意味着员工对象存在于多个文档中.
Consider a scenario where one employee is part of multiple teams. That means the employee object exists in multiple documents.
这可能导致:数据重复、需要更多存储空间、使更新变得多余.
Which can cause: data duplication, need more storage, make updates redundant.
这篇关于有嵌入的文档而不是依赖外键吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
