数据权限的设计与实现系列1——数据权限的设计与思考

大家好，欢迎来到IT知识分享网。

什么是数据权限？

权限控制是一个系统的核心功能，可以分为两类，一类是功能权限，一类是数据权限。数据权限又可以进一步分为行级权限和列级权限。

功能权限，是指系统用户能进行哪些操作，通常是菜单和按钮权限，如打开订单菜单，查询订单列表，创建新订单。对于功能权限，有标准化的解决方案，也即RBAC，通过权限项、角色、用户三张主表，以及角色-权限项对应关系表和角色-用户对应关系表两张辅助表，一共5张库表即可实现功能权限的功能，系统管理员通过系统界面即可实现灵活的权限分配和维护。

相比功能权限有标准解决方案RBAC，数据权限则没有所谓的标准方案，根源在于业务系统对于数据权限的控制需求，或者说控制维度是多种多样的，很难统一化或标准化。

开发平台或开发框架没有数据权限支撑会怎么样？

以上硬编码的方式，无论哪一种，都无法解决灵活性的问题，系统需求变更或新增，不得不调整编码，对应的开发成本和运维成本都比较高，优点是技术难度低，实现简单。

数据权限的控制维度有哪些？

虽然业务系统对于数据权限的控制需求，或者说控制维度是多种多样的，很难标准化，但是还是有一些常用的。

首先，组织机构是最常见，使用频率最高的一个的控制维度。对于一个集团公司，北京分公司与上海分公司，业务数据在公司范围内可见；公司内部不同部门，如采购部门和销售部门，业务数据在部门内范围内可见。

其次，角色也是经常会用到的，用于跨组织机构或没有系统内部的数据从属关系，例如，公司的几个高管，每人分管几个部门，某个高管，跟分管的部门之间从系统看是没有关联的，但客观又存在业务上的需要，高管能看到自己分管的部门数据。

再次，是与当前用户相关，如要求只有发帖人才能修改帖子内容。

最后，就是跟业务实体的具体属性相关了，例如，业务类型是采购还是销售，配送方式是自提还是送到，合同金额超过100万等。

控制维度是否需要组合？

上面说过，控制维度是多种多样的，常见的几个控制维度是组织机构、角色、人员相关，那么，实际需求是否存在多控制维度的组合呢？

进一步深入考虑，如果有5个高管，每名高管分管3-5个部门，按照上面方式处理，最后会拼成一个复杂的sql语句给执行层，一方面，肯定会影响系统执行效率与性能；另一方面从整个系统层面而言，每个业务实体，都需要给高管分配一遍，也相当繁琐，同样不合理。

这种情况，应该换一种解决思路，即按照分管部门，再虚拟出一个上级部门来，依旧按照组织机构来管理数据权限。

如果只通过角色来控制数据权限是否可行？

既然功能权限是基于角色的，那么数据权限是不是也可以这么做呢？这么做的一个显著好处是，使系统管理员可以在角色管理界面统一设置功能权限与数据权限。但深入考虑下，这么做是有问题的。首先，本来数据权限的控制是多维度，常见的需要根据组织机构、角色、用户进行控制，如基于角色，则相当于丧失了其他控制维度，某些数据权限控制需求是难以实现的。

例如，开发了一个功能，查看每月耗电量，要求各部门经理只能查看自己部门的数据，这种情况下，菜单肯定是同一个，如果不能按组织机构去进行数据权限控制，而是基于角色，会发生什么问题呢？这时候，不得不建立大量的角色，每个部门的部门经理都要建立一个单独的角色，如采购部经理，销售部经理，会发生角色爆炸问题，给系统的初始赋权和运维带来大量的工作。

好的数据权限设计要考虑哪些因素？

数据权限控制的最小单位是什么？

此外，实际对数据权限的控制，可以抽象成数据层面的查询、修改、删除，注意，这里没有新增，新增属于功能权限的管理范畴，数据是新增后产生的，新增前数据都不存在，谈不上数据权限管理。并且，实际的需求，高度集中在查询这个层面，修改和删除往往是明确的业务逻辑规则，可以固化在业务逻辑中。

开源平台资料