我目前正在设计一个数据库模型，我遇到了一个问题，在那里我想要更多关于什么被认为是正确的做事方式的输入。
在下面的例子中，我有两个表，Persons和Roles。 现在可以为1个人分配0个或更多角色。 这与多对多关系非常简单，但是当你想让用户选择他当前“正在”操作的角色时，就会出现棘手的部分。
假设用户有5个角色可供选择，并且根据他当前选择的角色，应用程序将向他显示不同的视图/菜单/按钮/等。
我在这里看到两个解决方案：
1 :(见下面链接的图像的顶部）
在人员表中，您可以将可空的FK包含在多对多关系中（关联实体）。
来自维基百科Associative entity
“其他实体”似乎可以引用这种关系。我不完全确定这是否包括角色和人员实体。
我喜欢这个设计的是，很容易获得一个人所有允许角色的列表，然后你只需指向其中一个允许的角色，说“你是当前/活跃的角色”。这也是一种确保用户只能拥有当前角色的好方法，如果他有权访问该角色......只有，我也看到了潜在的灾难： 如果，个人表中的FK引用了另一个用户的关系，那该怎么办呢？数据库设计允许这样做。它只是阻止它的代码。
2 :(见下面链接的图像的下半部分）
我保持关联实体的简单，而我在人员表中有FK指向Roles表中的特定角色。
这里的问题是我从数据库设计中得到的帮助更少，确保一个人的“当前角色”是一个实际上“允许”的角色。
对此的任何想法都将非常感激=）
更新：我将包含同一问题的另一种变体。
两个实体：WorkOrders和Sites
所以我们有多对多的关系
问题：当数据库中只有1个拥有工单的网站时，我们如何最好地存储数据库哪个网站是工作单的所有者。
我们是否将“OwnerSiteId”作为WorkOrder表中的列，或者可以引用多对多关系，并说“那个”是所有者。
答案 0 :(得分：0)
将当前角色与其他会话数据一起存储。
答案 1 :(得分：0)
如果您的要求是一个人可以有多个角色，但只能有一个活跃的角色
如果是，那么你的两个设计都有以下优点和缺点
- 设计1.在PERSON表中拥有ROLE表的密钥专业版：它将减少连接，因此在数据库操作上会降低成本。缺点：您可以为用户分配一个从未在其允许列表中的角色。
结论：如果我是你，我会去设计1并确保从应用程序中分配角色。
