权限设计在系统设计中无法回避，而且该模块处于牵一发而动全身基础地位，这里对设计思路简要分析。
首先，权限要区分开功能权限与数据权限。功能权限解决有没有的问题，而数据权限解决有多少的问题。而且权限设计思路会因为系统用户的结构形态不同而差异很大，这里只对一些基本的，通用的场景提供一个基本思路。
相比较而言，功能权限的设计会更通用一些。一般会将用户，角色关联，而角色又拥有某些具体地功能权限，从而达到用户--功能权限筛选的目的，如图：
对于数据权限的设计，我们要考虑即便在同一个系统中，会因为维度的不同，而产生多套数据权限系统，并且这些不同的系统数据可能会产生交叉。举例说明，一个大型连锁超市，它的部门结构如图所示：
不同层级，不同部门的员工，能够看到的销售数据，会因为部门不同产生差异，这属于从组织部门的维度出发而产生的数据权限；此时，我们考虑该超市属于全国连锁，经理可以看到全国的数据，而销售部只能看到本地区的销售数据，那么这里又是从行政区域的维度出发而产生的数据权限。
首先，我们来简单说明一种根据这种组织结构出发而形成的自上而下的数据权限，即从组织部门的维度出发产生的数据权限。例如，所有的员工信息USER表，而上图所示的层级为POSITION表，每个部门只能看到自己管辖范围内的员工信息，底层的员工只能看到自己的信息。此时还会有USER_POSITION_RELATION表用于存储每个员工对应的层级。如图：
此时，某用户登录时，可以首先找到他的user信息，进而找到他的职级，根据他的职级的字段path可以找到他的所有子节点信息，从而获取到一个List<Position>。在进入到对应的员工信息展示界面时，凡是符合这个List<Position>的员工信息都可以进行展示。这是一个最简单的数据权限的实例。
然后，我们再考虑一种因职能部门不同，而产生的数据权限。例如，在上述体系中，经理和信息部可以看到系统所有的订单信息，而销售部长可以看到所有的订单信息，但食品销售部只能看到食品订单信息，百货销售部只能看到百货订单信息，剩下的财务部和仓库管理部无法看到订单信息。此时除了上述的三张表，我们加入GOODS_ORDER商品订单表，GOODS_TYPE商品类型表，以及表示商品与可以查看的职级关系表GOODS_POSITION_RELATION表。
每个商品订单都会属于一种商品类型，而商品类型与职级产生关联之后，便可以实现该维度的数据权限。当用户登陆时，获取到他的职级，进而从GOODS_POSITION_RELATION表中获取这个职级能够查看所有的商品类型，即List<GoodsType>，在进入到页面时，所有符合这个List<GoodsType>的信息都能够展示。
上述两种数据权限的设计都是依赖于组织机构，在此基础上，进行数据与职级的关联，从而达到筛选数据的目的。如果这个职级不存在，我们也同样需要将用户的某种归集，与需要筛选的数据进行关联，从而达到用户--筛选数据的目的。
具体的场景中，一般还会有管理界面提供给管理员进行权限的配置，为了简化操作，一般会出现角色，权限的分组，以达到方便批量操作的目的，此时的表结构会比上述的模型更加复杂，设计时也需要具体情况具体分析，合理地设计，才能满组业务需求。