我们的一个项目中有一个小问题，其中两个投资者是建筑师，而且......通常在生活中，他们并没有真正相处一些想法。两者都与以前的项目有不同的经验，似乎他们看不起另一个项目的想法。是的，我是其中之一。
我们有一个关于如何在我们的项目中定义用户权限处理的争论。
一个想法是让表具有权限，角色收集权限集，然后是具有角色定义的用户。
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
我对第一个选项的看法是维护起来要便宜得多： 添加单个权限意味着它只是一个插入+处理代码中的权限。
如果是另一个（对我而言），则意味着您必须更改数据库，更改处理数据库的代码，并在此基础上添加代码以处理权限。
但也许我错了，我没有看到其他解决方案可能带来的好处。
我一直认为前者是处理它的标准，但我被告知这是主观的，在数据库中进行更改只是运行一个脚本（对我而言，这意味着脚本必须被添加到部署中，必须在每个数据库上运行，并且必须“记住”迁移等。）
我知道这个问题可能是基于意见的，但我有点希望，这确实是一个标准和良好实践的问题，而不是主观意见。
答案 0 :(得分：2)
我发布了一些其他问题作为对原始问题的评论。
即使你有一个完全平坦的角色设置，我也无法想出去寻找第二个提案的理由。正如你所说，改变某些东西需要修改代码和数据结构。
您的同事提出的是一种非规范化，只有在您需要优化处理大量数据的速度时才能防御。在处理角色时通常不会这样。
（例如，LDAP或其他通用单点登录模型采用更接近您的第一个解决方案的东西，因为即使在大型组织中，USERS的数量总是比ROLES的数量大至少一个数量级）。
即使您正在设计Facebook替代品（您可能拥有数十亿用户），您实际上不可能需要多个角色，因此这将是一个过早优化的情况（并且 - 很可能是 - 更糟糕的是优化错误的部分）。
<小时/> 从更广泛的意义上讲，我强烈建议阅读RBAC Wikipedia article以了解这类问题的标准方法。