数据库设计 - 关联实体

我目前正在设计一个数据库模型，并且遇到了一个问题，在哪里我想了解更多有关什么是正确的做事方式的输入。数据库设计 - 关联实体

在下面的例子中，我有两个表，人员和角色。现在1人可能被分配0个或更多角色。这与多对多的关系相当直接，但棘手的部分来自于当你想允许用户选择他当前“操作”的角色时。

假定用户有一个选择5个角色可供选择，并且根据他目前选择了哪个角色，应用将呈现与他不同的意见/菜单/按钮/等

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

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

在个人表，你有一个可以为空FK的许多一对多的关系（关联实体）。

它似乎确定为“其他实体”来引用这种关系。我只是不完全确定这是否包括角色和人员实体。

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

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

我把关联实体简单，而是我有FK在指向的角色表中的特定角色的人表。

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

Example image

任何对此的思考，将不胜感激=）

更新：我有同样的问题的另一种变体。

两个实体：工作订单和站点

1网站可以访问许多工作单
1工单可以被很多网站访问

因此，我们有一个多TO-许多关系

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

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

来源

2012-10-16 Trond Blomholm Kvamme

类似于：http://stackoverflow.com/questions/12652152/mysql-circular-dependency-in-foreign-key-constraints –

如果你的要求是：
一个人可以有多个角色，但只能有一个积极的作用
如果是比你的两个设计具有以下优点和缺点

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

设计（二）有PERSON表利弊副实体表的关键：人将被分配只有那些允许他中的作用。缺点：比第一种方法增加一个连接成本。

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

来源

2012-10-16 13:31:13 zaffargachal

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

来源

2012-10-16 13:15:21 Oswald

是的，对于这个问题，我可以看到这可能是一个解决方案。只有我看到这个问题也出现在其他变体中。示例：我们有两个其他实体WorkOrders和Sites。 WorkOrder由1个站点拥有，并可能与其他几个站点共享。在这里你再次得到问题。你有几个应该有权访问工作订单的网站，但其中只有一个是“所有者” –

@TrondBlomholmKvamme是的，但所有这些引用都是* transient *，不应该正式存储在数据库中：它是所有会话的东西。如果需要存储“当前”数据，则只需将其存储为实体的一列。否则，请考虑遵循奥斯瓦尔德的建议。 – Bohemian

数据库设计 - 关联实体

回答

相关问题