SQL数据库中的计划应用程序的表结构

我正在处理数据库以保存应召信息计划的信息。目前，我有一个看起来大约是这样的结构：SQL数据库中的计划应用程序的表结构

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

我的问题是：随着附表表，我应该离开它结构为是，其中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仍然相当新，所以我想确保在学习时使用最佳实践，以免我养成不良习惯。

来源

2012-11-04 The Astronaut

我建议编辑你的问题标题。 – undone

是的，我刚刚做到了。第一个标题令人困惑，我甚至没有意识到这一点。 –

（请考虑以下的建议，而不是批评。）如果表代表的实体，它往往是似乎最自然的由实体名称（是否使用单数或复数是称之为*高*有争议的，所以我没有在这个头上说什么），就像'人'一样。当另一个表本质上是两个实体之间的多对多关系时，通常使用两个实体的名称来调用它。所以，如果你喜欢，可以考虑它是否会为你工作更好，如果你叫'TeamIndex'表只是'Team'和'Teams'一个，'TeamPerson'（或者，也许，'PersonTeam'）。 –

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

更具体地说，我的看法是这样的：

如果业务需求是始终有召唤小和固定数量的人（比如，三），那么它可能是更方便地分配三列在Schedule，一个是每一支球队举行任命的人的ID，即像当前的结构：

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

与dt作为主键。

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

但是，即使这一要求是固定的，它可能只变成固定今天，明天你的老板说，“我们不再有固定数量的团队（呼叫）的工作”，或者“我们需要将支持的团队数量扩大到四个，我们可能需要在未来进一步扩展“。因此，一个更普遍的做法是你正在考虑在你的问题转换到一个，那就是

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

其中的主键现在是dt, Team。

这种方式，您可以轻松地扩展/减少的人数在数据库级的呼叫，而无需更改任何架构。

UPDATE

我忘了解决我原来的答复（对不起）你的第三个选择。开始。

你的第一选择（目前实际执行的）似乎暗示每个队可以只（不超过）一个人提出。如果您指定的代理ID，以个人/团队对并使用这些按键在Schedule，而不是单独的ID为Person和Team，你可能会无法“每队一人计划”实施所提到的要求（或者，至少，这可能会有点麻烦），而使用单独的密钥，只需将Team设置为组合键(dt, Team)的一部分即可完成，现在每天只有一个团队完成。

而且，你可能有让人变化团队随着时间的推移，如果他们在球队中存在以这种方式迷恋，即用Schedule参考个人/团队对困难。你可能将不得不改变在PersonTeam表中的队伍参考，这将导致对历史信息不实陈述：在人们对呼叫回头看某一天的时候，显示将是一个人的球队，他们属于现在，不是他们那时做的那个。

使用的人员和团队独立的ID在Schedule，另一方面，将允许你让人们改变球队自由，提供你不使(Schedule.Team, Schedule.Person)一个参考(PersonTeam.Team, PersonTeam.Person)，当然。

来源

2012-11-04 17:34:40

当前版本，每个团队一列，可能不是一个好主意。由于您代表的团队是一张表格（而不是一个枚举或等价物），这意味着您期望随着时间的推移添加/删除团队。这将迫使你添加/删除列到表中，这往往是一个比添加/删除几行更大的任务。
的第二选项是通常解决这样的问题。一个安全的选择。您始终可以定义从Schedule（teamID，personID）到PersonTeam的额外外键约束，以确保您不会错误地将计划任务分配给不属于该团队的人员。
第三选项是非常相当于第二，只有你对换PersonTeam复合自然键用于替代简单的键。由于所述组合密钥的两个组成部分已经是代理人，因此添加这个附加组合并不具有优势（就不变性等而言）。此外，它会变成一个非常简单的N-M关系（PersonTeam），大多数DB经理/ ORM将很好地处理成更复杂的对象，这将需要自行管理。

由奥卡姆的剃须刀，我会删除额外的代用钥匙，并使用你的第二个选项。

来源

2012-11-04 17:49:35 jsalvata

你的回答，更加完整的，提醒我，我忘了解决OP的第三个选项，谢谢。 –

SQL数据库中的计划应用程序的表结构

回答

相关问题