我建议选择“方法1”的一种变体——非分层角色。我曾在类似的系统中取得了巨大成功。虽然这种方法一开始可能看起来比较松散，但它相对简单且非常灵活，特别是在允许多个用户角色并定义聚合权限规则时。
反对使用分层（而不是角色）的原因之一是，就像“OO分层”一样，使用角色分层会导致严格的替换关系。这使得基于不断变化的需求来定义角色更加困难。例如，也许将来需要一个“管理员”账户，但该账户不能创建自己的帖子。由于“完全管理员”是“付费用户”，所以分层结构（及其具有的替换关系）会阻止此操作而不改变树结构本身。
针对真正的分层结构的查询在SQL中更加复杂，尤其是在不支持递归查询的实现中，如MySQL。切换到使用嵌套集或物化方法的分层会强制增加额外的结构，而不仅仅是父子关系。
您不需要它; 软件越复杂，编写和维护就越困难。虽然在某些情况下层次结构非常好用——例如在物料清单、家谱或目录结构中——但在大多数角色/组权限模型中根本没有“需要”。
对于（多）角色
没有“父类型”依赖关系的角色更像“OO接口”——如果比喻要被拉伸，那么
Trait composition可能更合适。每个角色的实现（即授予的权限）可以独立于任何其他角色而进行更改，使其极其灵活。与接口一样，可以将多个角色分配给给定的用户/实体。
针对平面
用户<M-M>角色<M-M>权限模型的查询在SQL中（带或不带递归支持或附加结构）更简单，因为根本没有需要遍历的角色层次结构。
Windows ACL Groups（忽略嵌套组）与角色非常相似；用户属于一个或多个组，该组授予权限(或拒绝权限，但这是不同的情况)。
既要有蛋糕，还要吃蛋糕
我建议采用上述提到的变化，允许在角色之间进行权限聚合。一个简单的聚合模型如下：
因此，权限被绑定到每个角色，几乎没有重叠，如“方法#2”所示，其区别在于：没有层次结构。
例如，为了允许一个特殊管理员搜索帖子（并删除“不良”帖子），只需分配“基本用户”和“有限管理员”角色1。
使用一个非分层的多角色系统可以使其更加清晰，摆脱分层的负担，同时提供灵活/可组合/可配置的角色原型。
1 这并不是一个特别好的例子。实际上，角色应该有不同的名称（例如“账户支持”或“内容审核员”），并且涵盖不同的权限集；这些权限集可能会根据试错和时下的业务规则而随时间变化。
虽然我反对为此类系统建立等级制度，但在更复杂的系统中，可能需要允许角色之间的关系，主要用于分组。这种关系通常应该是独立于有效权限的存在，用于其他管理目的。
