Question

我正在为将管理模型大会小组的应用程序进行数据库设计。对于代表大会的对象，我遇到了特别的麻烦。现在，字段列表如下所示：

    | Congress   |
    +------------+
    | congressID |
    | adminID    |
    | speakerID  |
    | hopperID   |
    | floorID    |
    | rulesID    |
    | (etc.)     |

这是每个字段的意思。表/对象都是上限。

congressID：主键（显然）
adminID：引用运行模型大会的唯一PERSON，即教师。
speakerID：引用作为大会发言人的独特REP（代表）
hopperID：引用特殊COMMITTEE（一个可以发送账单的任何地方的委员会），最初发送新账单。
floorID：引用用于代表大会楼层的COMMITTEE
rulesID：引用规则COMMITTEE

如您所见，这些字段对于每个模型大会的上下文都很重要。我遇到的问题是如何表示外键，主要是后四个。

似乎我有两个选择：

将它们全部包含在国会议席表中，或者
使用复合主键为每个字段制作较小的表格，例如扬声器中的repID + congressID，Hopper中的committeeID + congressID等

更细粒度一定更好吗？或者这不必要地复杂化了什么？我已经在第一次布局中绕过我的设计了一段时间，但每当我试图从那时开始绘制ERD时，这些关系就显得无可救药了。

Answer 1

群组应该是一个表格，可以简单地定义名称或描述中的会议号码（第1个，第2个等等），每个PERSON都应该有一个ID，其中包含姓名和个性化的字段。然后，M：N表（称之为GROUPMEMBERS）使用它自己的ID，引用GROUPS的ID和（PERSON或GROUPS - 将是两个字段，因此您可以将组附加到层次结构中的其他组）。然后，您有一个标签表（GROUPROLES），它有自己的ID，开始日期（可能是结束日期），对GROUPMEMBERS的引用，以及对TYPES表的引用，该表定义了成员中每行的一个角色。

这可以让你做什么？现在，一个人的角色可以通过附加到角色的日期来改变议会中期。委员会可以成为大会的一部分（在名称或名称中以代表大会的名义命名的小组），并且可以分配委员会（如主席）中的角色。

缺点？报道涉及一些体操，但并非不可能。表名不是直接相关的，但它们不需要暴露给应用程序用户。每组每个角色的成员数量限制需要在数据库中设置为自定义函数，或者由应用程序控制（不推荐）。

这也允许您设置通过委员会跟踪项目流的依赖基础设施，您甚至可以报告单个人通过其成员身份看到项目经历的组的次数。它还可以用于跟踪投票并将信息非规范化为大组投票（如基于投票在委员会中传递或死亡），只需在相关投票上运行汇总并引用该组即可。如果是这种情况，我可能会将角色作为历史表的子类，并从中心历史中运行所有内容。

何时使用较小的表格

1 个答案: