最佳用户角色权限数据库设计实践？ [关闭]答案

【问题标题】：Best user role permissions database design practice? [closed]最佳用户角色权限数据库设计实践？ [关闭]
【发布时间】：2018-02-11 10:58:37
【问题描述】：

我想为 Web 应用程序设计数据库，在该数据库中，用户可以根据授予角色的权限访问特定选项卡。

到目前为止，我创建了两个表 USER_TABLE 和 USER_ROLES。

USER_TABLE 具有以下字段：

USER_ROLES 具有以下字段：

在这里，角色名称为“ADMIN”的用户可以看到所有的标签，其他用户只能访问特定的标签。

我的问题是我是否需要在 USER_ROLES 表中创建一个具有外键的表 USER_PERMISSIONS，其中包含以下字段：

或者我应该在我的代码级别进行管理？这两种方法的优缺点是什么？

【问题讨论】：

这取决于您的要求。如果您只想实现在运行时无法更改的静态权限，则将所有应用程序的功能绑定到代码中的角色。优点 - 更易于实施，缺点 - 每次更改权限都需要更改代码。如果你想要动态权限，可以在运行时更改（例如 admin 可以直接在应用程序中编辑单个角色的权限），那么你需要USER_PERMISSIONS 表，并在代码中将每个应用程序的功能绑定到某个权限而不是角色.

【解决方案1】：

正如 krokodilko 在他的评论中所写，这取决于您需要的灵活性水平。
我已为我的一位客户实施了基于角色的权限，如下所示：

但我的要求是尽可能灵活，而且它是一个仍在增长的系统（6 年而且还在继续）。

我猜很多应用程序可以让用户扮演一对多的关系，而不是像我的情况那样多对多，但我不会在任何应用程序中硬编码权限或角色权限。

进一步解释：Role based security database design 我知道什么#？

【讨论】：

你能告诉更多关于 4 和 5 的信息吗？
它们只是多对多的桥接表，没什么好介绍的......
我得到的是；角色将类似于（管理员、帐户等权限将是角色想要访问的视图我没有得到的是剩余部分我将如何使用表 user_to_role 和 role_to_permission
@vikrant 实际上，Permission 可能不是此表的最佳名称。更合适的名称是securables - 表示只能通过授权访问的东西 - 该表应该包含每个安全对象的应用程序范围（或域范围）的唯一键 - 无论是路径，Windows 窗体，甚至一个按钮。虽然很灵活，但这仍然是一个简单的授权示例——这意味着授权本身是二进制的——它要么存在，要么不存在。不同的实现可能包含不同的授权级别——类似于“读/写/执行”等。
@ZoharPeled 非常感谢您与我们分享这个设计 :)，我将这些值用于 3) ：例如：post.read post.create post.comment.write post.all post。 none，all 是超级管理员角色，none 如果是禁止用户，并且应用程序中的每个操作在 3) 中都有一个权限条目