SQL DB中调度应用程序的表结构

我正在处理一个数据库来保存待命时间表的信息。目前，我有一个类似这样的结构：

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

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

我的问题是：对于时间表表，我应该保持它的结构不变，其中dt是唯一键，还是应该重新排列它，使dt是非唯一的，并且该表如下所示：

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

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相当陌生，所以我想确保在学习时使用了最佳实践，这样我就不会养成坏习惯

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

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

如果业务需求是始终有少量固定人数（比如三人）待命，那么在

计划中分配三列可能更方便，每个团队一列保留指定人员的ID，即与您当前的结构类似：

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

将
dt
作为主键

如果团队的数量（在
团队
表中）也是固定的，您可以像现在这样在列名中包括团队的名称/标志，但是如果团队的数量超过三个，并且只有
计划
中的团队数量被限制为三个，那么您可以只使用像
OnCallID1
这样的名称，
oncalid2
，
oncalid3

但是，即使这一要求是固定的，也可能只是在今天得到了固定的结果，而明天你的老板会说，“我们不再与固定数量的团队（随时待命）”或者“我们需要将支持的团队数量增加到四个，我们可能需要在将来进一步扩大”。所以，一个更普遍的方法是你在你的问题中考虑转换到的方法，即

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

主键现在是
dt，Team

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


更新

我忘了在我原来的回答中提到你的第三个选项（对不起）。来吧

您的第一个选项（目前实际实现的选项）似乎意味着每个团队只能由（不超过）一个人呈现。如果您将代理ID分配给人员/团队对，并使用
计划中的那些键，而不是
人员
和
团队
的单独ID，则您可能无法在数据库级别强制执行所述的“计划中每个团队一人”要求（或者，至少，这可能会有点麻烦），使用单独的键，只需将
Team
设置为复合键
（dt，Team）
的一部分就足够了，现在您完成了，每天不超过一个团队

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

另一方面，在
时间表
中为人员和团队使用单独的ID将允许人们自由地更改团队，前提是您不将
（Schedule.Team，Schedule.Person）
作为
（PersonTeam.Team，PersonTeam.Person）
的参考。
目前的版本，每个团队一个专栏，可能不是一个好主意。由于您将团队表示为一个表（而不是枚举或等效项），这意味着您希望随着时间的推移添加/删除团队。这将迫使您向表中添加/删除列，这总是比添加/删除几行大得多的任务

第二种选择是解决此类问题的常用方法。一个安全的选择。您始终可以从Schedule（teamID，personID）到PersonTeam定义一个额外的外键约束，以确保不会错误地将日程职责分配给不属于团队的人员

第三个选项与第二个选项相当，只是您要将复合自然密钥替换为PersonTeam，以替换为代理简单密钥。由于所述复合密钥的两个组件已经是代理，因此添加此附加组件没有任何好处（在不变性等方面）。此外，它还将把大多数DB管理器/ORM都能很好地处理的非常简单的N-M关系（PersonTeam）转变为一个更复杂的对象，需要自己管理


根据Occam的剃刀，我会去掉额外的代理键，使用你的第二个选项。
我建议编辑你的问题标题。是的，我刚刚做了。第一个标题是疯狂的混淆，我甚至没有意识到。（请考虑下面的建议，而不是批评。）如果一个表代表一个实体，它通常是最自然的，用实体名称来称呼它（无论使用单数还是复数都是有争议的，所以我在这头上什么也没说），比如<代码>人>代码>。当另一个表本质上是两个实体之间的多对多关系时，使用这两个实体的名称来调用它通常很方便。所以，如果你喜欢，考虑它是否会为你打赌