用户及权限管理涉及的几个概念
用户分类：系统用户、超级用户、管理员用户、DBA用户、领导用户、专家用户、操作员用户、客户用户、……
系统权限：即对不同用户使用系统资源（功能菜单项、按钮、输入控件等）的使用或访问权限
用户：应用系统的具体操作者，用户可以拥有一定范围的权限
角色：为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色
组：为了更好地管理用户，对用户进行分组归类，简称为用户分组，如普通QQ群、高级QQ群；一级单位用户、二级单位用户等
权限、用户、角色、组之间的关系
用户的权限集 ＝ 自身的权限 ＋ 所属的各角色权限 ＋ 所属的各组权限
用户及权限管理设计方案
1. 基于角色的权限设计
最常见也是比较简单的方案，通常这种设计已经足够。
该模式下每一个“操作”都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录
问题：如果直接使用上面的设计，会导致数据库中的UserAction表数据量非常大，需要进一步设计提高效率。
2. 基于操作的权限设计
问题：如果直接使用上面的设计，会导致数据库中的UserAction表数据量非常大，需要进一步设计提高效率。
3. 基于角色和操作的权限设计
该方案是对方案2的改进：添加了Role和RoleAction表，从而可以减少UserAction中的记录，并且使设计更灵活
不足：经常需要定义新的“角色” 例如：当用户要求临时给某位普通员工某操作权限时，就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色
不足：经常需要定义新的“角色” 例如：当用户要求临时给某位普通员工某操作权限时，就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色
4. 精确至数据记录的权限设计
该方案需要对每一种不同的资源创建一张权限表
例如：上图中对Content和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限。
优点：比较灵活，可以对设置各种权限，对于不同的资源可以有自己的一套方案。
不足：该设计可以满足用户需求但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记录所有的记录的权限信息，有时候可能只是一种规则，比如说对于跟Channel什么级别的人有权限，这时我们就可以定义些规则来判断用户权限。
权限、用户、角色、组之间的关系
496
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
