关系多余？

Question

我正在设计一个数据库，我有一个用户表和一个包含用户组的组表。

这些群组将拥有所有者（已创建该用户的用户），以及属于该群组的一组用户（如Whatsapp群组）。

为了表示这一点，我有这样的设计：

您认为owner表上的Group列是否必要？也许我可以在owner表格上添加Group列我可以很容易知道该集团的所有者。

Answer 1

如果您未在owner中添加group，那么您要在哪里添加它？除此之外我唯一看到的方法是向isowner添加一个布尔usergroup。无论如何，如果只有1个所有者，那就没有意义。如果可以有N所有者，那么这将是最佳选择。

Answer 2

您需要4张桌子：

• 用户

• 用户组

• 组

• UserRole（与UserGroup关联） - 显示用户在组中的角色（管理员/所有者等） - 如果您的角色是Admin和普通用户，则可以使用UserGroup上的Binary列。

Answer 3

您走在正确的轨道上，但是您需要再做一步，以确保所有者必须真正属于她所拥有的群组：

组{groupID，owner}中有一个引用UserGroup {groupID，userID}的FOREIGN KEY。

如果您的DBMS支持延迟外键，您可以使所有者NOT NULL，以确保组不能是所有者。否则你可以让它为NULL（如果你的DBMS支持MATCH SIMPLE FK，你仍然可以通过循环引用打破“鸡与蛋”问题 - 几乎所有人都这样做。）

Answer 4

我知道已经提出了一个解决方案，但我确信有一个更好的解决方案......

在更高级别，所有者的概念可以被视为 作为用户和群组之间存在的关系的属性 。理想情况下，应将其设置为 UserGroup表中的字段 。

它可以是布尔字段，或者更好的是广义userGroupNatureOfRelation字段，它可以包含诸如“所有者”，“参与者”，“用户”或任何可能是状态的值。< / p>

当然，这样的解决方案允许您实施任何特定的业务规则，例如“每个组只有一个所有者”。它可以让您在需要时实施任何其他更复杂的业务规则，甚至可以通过添加以下字段来增加复杂程度：

• userGroupRelationStartDate
• userGroupRelationEndDate

你可以通过时间跟踪一个团队与一个人之间关系的本质......

当然你可以说'我不需要它'。但实施这样一个“开放”的模式并不比你现在想的更多。然后，如果出于任何原因，在近期或远期，业务规则必须改变或改进，您的模型将保持有效和高效......

这就是说，使用这个模型构建视图和操作数据应该会容易得多。所以这是采用它的一个好的和直接的理由！