1

我目前正在设计一个数据库模型，我遇到了一个问题，我想就什么被认为是正确的做事方式提供更多的输入。

在下面的示例中，我有两个表，Persons 和 Roles。现在可以为 1 个人分配 0 个或多个角色。对于多对多关系，这非常简单，但是当您希望允许用户选择他当前“操作”的角色时，就会出现棘手的部分。

假设用户有 5 个角色可供选择，根据他当前选择的角色，应用程序将为他呈现不同的视图/菜单/按钮/等。

我在这里看到两个解决方案：

1：（见下面链接的图片顶部）

在persons 表中，您将一个可为空的FK 包含到多对多关系（关联实体）中。

来自关联实体的维基百科

“其他实体”似乎可以引用这种关系。我只是不完全确定这是否包括 Roles 和 Persons 实体。

我喜欢这个设计的一点是，很容易获得一个人所有允许角色的列表，然后你只需指向其中一个允许的角色，说“你是当前/活跃的角色”。这也是确保用户只能拥有当前角色的好方法，如果他有权访问该角色......只是，我在这里也看到了潜在的灾难：如果，persons 表中的 FK 引用另一个用户的关系。DB 设计允许这样做。它只会是阻止它的代码。

2：（见下面链接的图片底部）

我使关联实体保持简单，相反，我在persons 表中有FK，它指向Roles 表中的特定角色。

这里的问题是，在确保一个人的“当前角色”实际上是“允许”的角色方面，我从数据库设计中获得的帮助更少。

示例图片

对此的任何想法将不胜感激=）

更新：我将包括同一问题的另一个变体。

两个实体：WorkOrders 和 Sites

  • 1 个站点可以访问许多工作订单
  • 许多站点可以访问 1 个 WorkOrder

所以我们有一个多对多的关系

问题：当只有一个站点拥有一个工作订单时，我们如何最好地在数据库中存储哪个站点是工作订单的所有者。

我们是否将“OwnerSiteId”作为 WorkOrder 表中的一列，或者可以改为引用多对多关系，说“那个”是所有者。

4

2 回答 2

0

将当前角色与其他会话数据一起存储。

于 2012-10-16T13:15:21.143 回答
0

如果您的要求是
一个人可以担任多个角色，但如果是，则只能担任一个积极角色
，那么您的两种设计都具有以下优点和缺点

-设计 1. 在 PERSON 表中拥有 ROLE 表的键优点：它会减少连接，因此会降低数据库操作的成本。缺点：您可以为用户分配一个从未出现在其允许列表中的角色。

  • 设计 2. 在 PERSON 表中拥有 Associate Entity 表的键 pros:PERSON 将只分配给他允许的那些 ROLES。缺点：比第一种方法增加了一个连接成本。

结论：如果我是你，我会选择设计 1 并确保从应用程序中分配角色。

于 2012-10-16T13:31:13.617 回答