如何建模：团队 <-(1) --- (N)-> 员工，有一个转折；更好的模式？答案

【问题标题】：How to model: Team <-(1) --- (N)-> Employees, with a twist; Better Pattern?如何建模：团队 <-(1) --- (N)-> 员工，有一个转折；更好的模式？
【发布时间】：2016-01-03 04:13:16
【问题描述】：

我必须在 SQL Server 数据库中建模并创建一个简单的关系...

一个团队可以分配零个或多个员工；一个员工只能分配给一个团队。很简单...这是我正在努力解决的问题...

团队有一个 TeamLeader，他是一名员工。 TeamLeader 可以分配给单个团队。因此，我将 TeamLeaderId long 添加到 Team 中，并给 TeamLeaderId 一个唯一索引。我在 Team to 中的 TeamLeaderId 和 Employees 中的 EmployeeId 之间创建了外键关系。

这是适合这种情况的最佳模型，还是有更好的模式？

感谢您的帮助和指导，

迈克

【问题讨论】：

您的解决方案是正确的。如果您需要在数据库级别确保此规则，您的唯一索引是最简单的方法（大多数时候最简单的解决方案是最好的解决方案）。

标签： entity-framework oop design-patterns database-design

【解决方案1】：

对于您列出的约束，这看起来是正确的。但似乎在 Team 和 Employee 之间建立一个链接表会更好。为什么要将员工限制在一个团队中，或者强制员工必须加入一个团队？今天有人（你？）可能认为这是唯一的方法，明天可能会有所不同。

【讨论】：

这违反了 YAGNI 原则。
YAGNI（我必须查一下）非常适合易于更改或扩展的东西。然而，这是您的数据库结构，它位于系统的根目录。也就是说，依赖于您将在其之上创建的所有内容。考虑到自我施加的限制违背了常见的现实世界场景并且现在覆盖这些场景会很便宜，YAGNI 很可能会在以后咬你一口。而且会很痛苦。我什至会说，不恰当的 YAGNI 承担了当今大部分软件开发费用。
不过，它可能不是 YAGNI 来设置可以更轻松地修改系统而无需担心的设施，即：自动化测试、数据库迁移等。我相信，一如既往，“这取决于”！ ?
感谢您的链接。它同意它确实取决于。通常我会同意 Sam 的观点，宁愿完成工作也不愿半途而废。典型案例是某种组件。 YAGNI 会告诉你只实现你现在需要的部分。您最终将得到一个仅适用于您正在处理的问题的组件。下一个家伙将不得不围绕着你半生不熟的组件来完成它，或者更糟的是，只需添加他需要的功能。否则他不会注意到您的组件功能失调并通过使用它来引入错误。那是维修地狱。而且价格可能高得难以想象。

【解决方案2】：

最好从 Team 表中删除 TeamLeaderId 字段并创建新表 TeamLeaders（具有唯一键 [EmployeeId in Employees + TeamId in Teams]）

现在，您可以改变主意并从您的业务领域模型中删除团队领导者，而无需付出任何代价：只需删除团队领导者表即可。

【讨论】：

【解决方案3】：

我认为这个问题的答案很大程度上取决于系统的使用情况：

如果创建了团队并分配了员工，然后最终从任何团队成员中选出了团队负责人，那么这是您做出的正确选择。
另一方面，如果员工被聘为团队负责人，并且他将始终被分配为团队负责人，则最好将这种“类型”信息添加到员工表中（或者添加/删除员工需要额外的不需要的逻辑来处理 TeamleaderId 和潜在的未来“类型”）。

【讨论】：