多对多的层次关系

Question

在我的应用程序中，我有三个主要表：

1. 用户
2. 组
3. 作用

任何组合都有多对多关系。例如。用户可以在不同的组中，每个组中都有不同的角色。

最简单的部分是映射用户和组，由中间表User_Group完成。然后，当设计如何将三者连接在一起时，我有一些疑问。



问：我是否在User_Group中添加了另一列？或者创建额外的中间表？

考虑第二种选择，我尝试了这个：



（我认为）会更容易，更整洁地检索前端需要的信息：

1. 可供用户使用的群组（User_Group）
2. 可用于群组的角色（Group_Role）
3. 可供给定群组中的用户使用的角色（user_Group_Role）

Answer 1

我会在现有的连接表中添加其他列。你仍然可以很容易地回答你的所有问题：

1. 可供用户使用的群组

   select *
   from Roles r
   join JoiningTableName j on r.Role_Id = j.Role_Id
   where j.User_Id = myUserId
   

2. 可用于群组的角色

   select *
   from Roles r
   join JoiningTableName j on r.Role_Id = j.Role_Id
   where j.Group_Id = myGroupId
   

3. 可供给定组中的用户使用的角色

   select *
   from Roles r
   join JoiningTableName j on r.Role_Id = j.Role_Id
   where j.User_Id = myUserId and j.Group_Id = myGroupId
   

Answer 2

我认为您在帖子末尾提出的架构没有任何问题。

• 确保user可以与group相关联，而不需要role group内的user。

• 它可以确保role只能使group适用于特定的role。

• 它可以允许在多个groups之间共享相同的group。

• 它可以允许roles没有任何doesn't have a role in this group

要缩小架构，可以提出一些漂亮的技巧：

• 为user_group创建一个角色;删除dummy user

的需要

• 为每个组创建一个group_role，该组具有该组有资格获得的每个角色;删除{{1}}

的需要

• 等，等

这里的缺点是你最终需要定制的代码来处理更改或强制执行约束。您在帖子末尾提出的架构可以使用外键约束和复合主键约束强制执行所有必需的约束。并且通常会对未来的变化更加灵活。

我认为没有理由不使用你提出的架构，它看起来完全正确，可维护，易懂和适应我。