前言

前一篇文章《通用权限管理设计 之 数据库设计方案》介绍了【主体】- 【领域】 - 【权限】( who、what、how问题原型 ) 的设计思想

本文将对这种设计思想作进一步的扩展，介绍数据权限的设计方案。

权限控制可以理解，分为这几种 ：

【功能权限】：能做什么的问题，如增加产品。
【数据权限】：能看到哪些数据的问题，如查看本人的所有订单。
【字段权限】：能看到哪些信息的问题，如供应商账户，看不到角色、 部门等信息。

上面提到的那种设计就是【功能权限】，这种设计有一定的局限性，对于主体，只能明确地指定。对于不明确的，在这里可能就没办法处理。比如下面这几种情况：

数据仅当前部门及上级可见
数据仅当前用户(本人)可见

类似这样的就需要用到上面提的数据权限。

上一篇文章我用一个表五个字段完成了【功能权限】的设计思路
本文我将介绍如何利用一个表两个字段完成这个【数据权限】的设计思路

初步分析

【数据权限】是在【功能权限】的基础上面进一步的扩展，比如可以查看订单属于【功能权限】的范围，但是可以查看哪些订单就是【数据权限】的工作了。

在设计中，我们规定好如果没有设置了数据权限规则，那么视为允许查看全部的数据。

几个概念
【资源】：数据权限的控制对象，业务系统中的各种资源。比如订单单据、销售单等。属于上面提到的【领域】中的一种
【主体】：用户、部门、角色等。
【条件规则】：用于检索数据的条件定义
【数据规则】：用于【数据权限】的条件规则 

 
应用场景
1，订单，可以由本人查看 
2，销售单，可以由本人或上级领导查看 
3，销售单，销售人员可以查看自己的，销售经理只查看 销售金额大于100,000的。

我们能想到直接的方法，在访问数据的入口加入SQL Where条件来实现，组织sql语句：

1，where UserID = {CurrentUserID}

2，where UserID = {CurrentUserID}  or {CurrentUserID} in (领导)

3，where UserID = {CurrentUserID}  or ({CurrentUserID} in (销售经理)  and 销售金额 > 100000)

这些一个一个的"条件"，本文简单理解为一个【数据规则】，通常会与原来我们前台的业务过滤条件合并再检索出数据。

这是一种最直接的实现方式，在【资源】上面加一个【数据规则】（比如上面的三点）。这样设计就是

　　【资源】 - 【数据规则】

我又觉得不同的人应该对应不同的规则，那么也可以理解为，一个用户对应不同的角色，每一个角色有不一样的【数据规则】，那么设计就变成

　　【资源】 - 【主体】 - 【数据规则】

根据提供者的不同，准备不同的权限应对策略。

这里可以简单地介绍一下，这个方案至少需要2张表，一个是  【资源，主体，规则关系表】、一个是【数据规则表】

关系表不能直接保存角色，因为你不确定什么时候业务需要按照【部门】或者【分公司】来定义数据规则

于是可以用  Master、MasterKey  类似这样的两个字段来确定一个【主体】

用XML方式的话是这样配置的(放在数据库也类似)：