数据建模，我应该使用多少个 fk？答案

【问题标题】：data modelling, how many fk should i use?数据建模，我应该使用多少个 fk？
【发布时间】：2014-02-16 17:49:47
【问题描述】：

假设你有以下架构。

用户有很多部门，(fk user_I'd)

每个部门 HV 许多办公室（fk department_I'd）

每个 office HV 许多事务（遇到 s）（fk office_id）

现在的问题是，如果我想获取用户的所有遭遇，我将需要搜索用户部门 s 中办公室的所有 encoutet。

你不觉得有很多连接吗？

但是，如果我在遇到表中包含树的所有外键？那我就可以select * from encounters where user_I'd = X

然而，这让我的表格看起来很丑陋，并且包含很多我想要的父母的重复数据！

所以我的问题是，在这种情况下最佳做法是什么？更多或更少的 fk 并使用连接？

【问题讨论】：

你的商业模式中遇到了什么？我认为答案可能还取决于您需要请求用户的遭遇与办公室的遭遇的次数。如果你只关心用户的遭遇，那么你应该改变你的模型来减少这个请求的连接。如果这是一个罕见的请求，则可以使用最慢的请求以获得更清晰更自然的设计。
dan ehr 系统，遭遇是通常发生在办公室内的医患互动——但一次遭遇可以有很多医生.. 为了举例，我保持简单

标签： mysql database database-design backbone-relational

【解决方案1】：

当我设计我的表时，我通常不会做任何冗余，而是将多个连接的复杂性保留在服务器端代码的 服务层 中。当您以后想要更改设计时，它可以提供更大的灵活性。

这可能是宗教问题而不是纯粹的逻辑问题，因此您可能需要更多类似的答案来决定。

【讨论】：

我喜欢这样..但不确定我是否能承受这种对性能的灵活性影响，但我会记住它:)，谢谢

【解决方案2】：

首先，层次结构确实没有那么糟糕。如果您要进行大量查询以获取与特定用户关联的所有遭遇，请创建视图。这可能看起来像：

create view Encounters as
select
    Transactions.Id as TransactionId,
    Offices.Id as OfficeId,
    Departments.Id as DepartmentId,
    Users.Id as UserId
    -- other fields
from Transactions
join Offices on Transactions.OfficeId = Offices.Id
join Departments on Offices.DepartmentId = Departments.Id
join Users on Departments.UserId = Users.Id

这样您就可以对任何 Id 字段执行查询，而无需每次都重新创建连接，select * from Encounters where UserId = 12345

【讨论】：

【解决方案3】：

我自己不会经常打电话给三个人。了解非规范化遇到表的好处是否超过成本的唯一方法是查看您是否遇到问题并通过非规范化解决它。在我看来，现在做出这个决定还为时过早。

【讨论】：