【发布时间】：2018-07-05 14:09:24
【问题描述】：
在我们的一个项目中遇到了一个小问题，其中有两个投资者是建筑师，而且......就像生活中通常的情况一样，他们并没有真正理解其中的一些想法。两人之前的项目经历不同，似乎都看不起对方的想法。是的，我就是其中之一。
我们对如何在我们的一个项目中定义用户权限处理存在争论。
一个想法是让表具有权限、收集权限集的角色以及定义角色的用户。
User
user_id
role_id
Role
role_id
permission_id
Permission
permission_id
另一方想建议使用具有定义权限的列的表来做到这一点：
User
user_id
role_id
Role
role_id
can_do_something
can_do_something_else
can_do_something_even_different
我对第一个选项的看法是维护成本要低得多： 添加单个权限意味着它只是一个插入+代码中权限的处理。
如果是另一种情况（对我来说），这意味着您必须更改数据库，更改处理数据库的代码，然后添加代码来处理权限。
但也许我错了，我没有看到其他解决方案的一些可能的好处。
我一直认为前者是处理它的标准，但我被告知这是主观的，并且在数据库中进行更改只是运行脚本的问题（对我来说这意味着脚本必须添加到部署中，必须在每个数据库上运行，并且在迁移的情况下必须“记住”等）
我知道这个问题可能是基于意见的，但我有点希望，这确实是一个标准和良好做法的问题，而不是主观意见。
【问题讨论】：
-
你的角色模型是扁平的，还是有排序的层次结构？即，如果我说“Root”，我是否会自动获得“NormalUser”和“AreaManager”的所有权限（这又是“高于”普通用户，因此它也具有 NormalUser 权限？）。或者，角色可以是其他角色的成员，还是只有用户可以与角色关联？用户只有一个角色，还是多个角色？
-
用户是否会获得一组上下文数据来配合他们的角色？ IE。如果我是区域经理，我是否会在某个地方获得区号（以识别我管理的区域，然后我在该区域具有更新权限，但在其他区域具有只读权限？） - 这也可能包括，对于经理，谁向他/她报告，所以我可能有权添加或删除我“下”的用户，但不允许对其他部门的用户进行更新。
-
@p.marino：root 角色必须添加所有必需的权限。角色将不包含指向其他角色的链接。我们不希望与区域相关，它更像是与客户相关。如果您是客户并且您创建了经理，您将为其应用角色。您可以为此创建自己的角色。
-
根据我的经验，让角色可组合通常更好。 IE。您将角色设计为 HeadLibrarian，然后使其成为角色 Staff、Library Users、Dept.Manager 的成员。为什么？因为当您的图书馆馆长 John Smith 离开公司并由 Susan Black 接替时，您将只需要为她分配一个角色，而不是 3 个（并且您只需删除辞职者的一个角色关联，而不是三）。当然是 YMMV - 我的经验是在拥有数千名员工、数十个角色和数十个部门或数据集的公司中授予权限。
-
还有一件事：GUI 是否必须查询角色才能决定显示哪些元素或使其可操作？ （例如 Role=Manager 将使按钮“FireOnTheSpot”在 GUI 上可见并处于活动状态），而按钮 EditProfle 将对所有人可见但仅在您查看自己的个人资料时才处于活动状态？
标签： database design-patterns architecture