5

我正在开发一个数据库来保存待命时间表的信息。目前我有一个看起来像这样的结构：

Table - Person: (key)ID, LName, FName, Phone, Email
Table - PersonTeam: (from Person)ID, (from Team)ID
Table - Team: (key)ID, TeamName
Table - Calendar: (key dateTime)dt, year, month, day, etc...
Table - Schedule: (from Calendar)dt, (id of Person)OnCall_NY, (id of Person)OnCall_MA, (id of Person)OnCall_CA

我的问题是：对于Schedule表，我应该将其保持原样，其中 dt 是唯一键，还是应该重新排列它以使 dt 不唯一并且表如下所示：

Table - Schedule: (from Calendar)dt, (from Team)ID, (from Person)ID

并且每天有多个条目，或者只使用：

Table - Schedule: (from Calendar)dt, (from PersonTeam)KeyID - [make a key ID on each of the person/team pairings]

一个团队总是会有人随叫随到，但一个人一次可以为多个团队随叫随到（如果他们在多个团队中）。

如果完全不同的设置会更好，请告诉我！

谢谢你的帮助！如果我的问题不清楚，我深表歉意。我学得很快，但每天使用 SQL 还是相当新的，所以我想确保我在学习时使用最佳实践，这样我就不会养成坏习惯。

4

2 回答 2

2

  • 当前版本，每个团队一栏，可能不是一个好主意。由于您将团队表示为表格（而不是枚举或等效项），这意味着您希望随着时间的推移添加/删除团队。这将迫使您向表中添加/删除列，这总是比添加/删除几行更大的任务。

  • 第二个选项是此类问题的通常解决方案。一个安全的选择。您始终可以从 Schedule(teamID, personID) 到 PersonTeam 定义一个额外的外键约束，以确保您不会错误地将计划职责分配给不属于团队的人员。

  • 第 3 个选项几乎等同于第 2 个选项，只是您将 PersonTeam 的复合自然键交换为代理简单键。由于所述复合键的两个组件已经是代理项，因此添加这个额外的组件没有任何优势（在不变性等方面）。此外，它会将大多数数据库管理器/ORM 可以很好地处理的非常简单的 NM 关系（PersonTeam）变成一个需要自行管理的更复杂的对象。

根据奥卡姆剃刀，我会取消额外的代理键并使用您的第二个选项。

于 2012-11-04T17:49:35.843 回答
1

在我看来，答案可能取决于团队的数量是否固定且相当少。当然，团队的名称是否固定也可能很重要，但这可能更多地与列命名有关。

更具体地说，我的观点是：

如果业务需求是始终有少量且固定数量的人员（例如三个）待命，那么在 中分配三列可能会更方便Schedule，每个团队一个用于保存指定人员的 ID，即就像你现在的结构：

dt   OnCall_NY  OnCall_MA  OnCall_CA
---  ---------  ---------  ---------

以dt作为主键。

如果团队的数量（在Team表格中）也是固定的，您可以像现在一样在列名称中包含团队的名称/代号，但如果团队的数量超过三个并且它只是团队的数量Schedule仅限于三个，那么您可以只使用OnCallID1, OnCallID2,之类的名称OnCallID3。

但即使这个要求是固定的，它也可能只是在今天得到固定，明天你的老板说，“我们不再与固定数量的团队合作（待命）”，或者“我们需要扩大支持的团队数量到四个，我们将来可能需要进一步扩展”。因此，一种更通用的方法是您正在考虑在您的问题中切换到的方法，即

dt   Team  Person
---  ----  ------

主键现在在哪里dt, Team。

这样，您可以轻松地扩展/减少数据库级别的待命人数，而无需更改架构中的任何内容。

更新

我忘记在我的原始答案中解决您的第三个选项（对不起）。开始。

您的第一个选项（目前实际实施的选项）似乎暗示每个团队只能由（不超过）一个人呈现。如果您将代理 ID 分配给 Person/Team 对并使用这些键Schedule而不是单独的 ID 用于Personand Team，您可能无法强制执行提到的“计划中每个团队一个人”要求（或者，至少，这可能证明有点麻烦）在数据库级别，而使用单独的键，设置Team为复合键的一部分就足够了(dt, Team)，你就完成了，现在每天不超过一个团队。

此外，如果一个人在团队中的存在以这种方式固定，即参考个人/团队对，您可能难以让一个人随着时间的推移改变团队。Schedule您可能必须更改PersonTeam表中的团队参考，这会导致历史信息的错误陈述：查看某天回电的人员时，显示的人员的团队将是他们现在所属的团队，而不是那个团队他们当时做到了。

另一方面，在 中为人员和团队使用单独的 ID Schedule，可以让人们自由地更改团队，当然前提是您不(Schedule.Team, Schedule.Person)引用(PersonTeam.Team, PersonTeam.Person)。

于 2012-11-04T17:34:40.063 回答