以我的经验，真正的问题主要归结为是否将发生任何数量的特定于用户的访问限制。
例如，假设您正在设计社区的架构，并且允许用户切换其个人资料的可见性。
一种选择是坚持使用公共/私有配置文件标志，并坚持进行广泛的先占权限检查：“ users.view”（查看公共用户）与例如“
users.view_all”（查看所有用户，对于主持人） 。
另一个涉及更精细的权限，您可能希望他们能够进行配置，以便他们可以使自己（a）所有人都可以看到，（b）亲手挑选的伙伴可以看到，（c）完全保密，甚至（d
），但由他们手工挑选的bozo除外。在这种情况下，您需要为各个行存储与所有者/访问相关的数据，并且需要对其中的一些内容进行大量抽象，以避免实现密集的，面向图的传递闭包。
无论采用哪种方法，我都发现，角色编辑/分配中增加的复杂性被 分配 给各个数据段的权限所带来的轻松/灵活性所抵消，并且以下各项效果最佳：
- 用户可以具有多个角色
- 角色和权限合并在同一个表中，带有标志以区分两者（在编辑角色/权限时有用）
- 角色可以分配同一表中的其他角色，角色和权限可以分配权限（但权限不能分配角色）。
然后，可以在两个查询中提取生成的面向图，使用您使用的任何一种语言，在合理的时间内一劳永逸地构建所有内容，并将其缓存到Memcache或类似物中以供后续使用。
从那里开始，获取用户的权限就是检查他拥有哪些角色，并使用权限图对其进行处理以获取最终权限。通过验证用户是否具有指定的角色/权限来检查权限。然后基于该权限检查运行查询/发出错误。
如果需要，您可以扩展对单个节点的检查（例如
check_perms($user, 'users.edit',$node)，“可以编辑此节点”与
check_perms($user,'users.edit')“可以编辑一个节点”），并且最终用户可以使用非常灵活/易于使用的工具。
如开头的示例所示，请警惕过多地转向行级权限。性能瓶颈在检查单个节点的权限方面要比拉出有效节点列表（即仅用户可以查看或编辑的节点）少。如果您不太（非常）精通查询优化，则建议不要在行本身内的标志和user_id字段之外进行任何操作。
