Mysql 用户角色模式设计比较

我正在学习如何设计一个数据库结构，为用户分配访问特定页面的权限

• 如果用户是管理员，则该用户可以访问crud操作
• 如果用户是编辑器，则该用户只能访问“编辑”
• 用户可以拥有自定义权限，然后根据配置进行访问

我有两个模式设计，两个都很好，一个需要简单的查询，另一个可以包含关于每个角色和权限的更多描述

设计1

角色id存储在名为

user

的表中，我需要查找

role\u has\u permission

table获取所有权限id，然后查找

permission

table以获取

permission\u name

列。相对较长的查询，获取的数据较多，但我可以在

权限

表中设置

说明

列

设计2

角色id存储在用户表中，我可以简单地进行单个查询并检查权限。例如：

role.canEdit

设置为true，允许用户进行编辑。更小更快的查询

---

为什么我不能采用第二种设计？为什么许多文章都采用第一种设计？

design 1允许您在不更改软件的情况下动态添加权限。如果您需要一个新的权限，比如说

可以为整个团队预订午餐

，您只需在

权限

表中添加一条记录，并且

角色中的所有人都拥有所需的权限

，就完成了。在设计2中，您必须添加一个操作

canorderlunchforentiteam

。因此，设计1更灵活

---

然而，设计1的灵活性是有代价的。仅定义和分配这些权限是不够的，但软件可能还应在执行功能时检查这些权限。添加用于订购午餐的函数是一种软件更改，因此向design 2类添加属性可能是可以接受的。因此，在design 1中定义权限的通用方法只有在您实现了一种类似的通用方法来应用它们时才会奏效。

json很难更新，第一种方法是规范化的，没有冗余