【自然框架】之通用权限：数据库设计的几种使用方式

63 阅读 0 评论 42 点赞

我是靠谱客的博主曾经招牌，最近开发中收集的这篇文章主要介绍【自然框架】之通用权限：数据库设计的几种使用方式，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

上次《【自然框架】之通用权限：用PowerDesigner重新设计了一下数据库，有ER图和表关系图》里说了一大堆的表，好多人说太复杂了，做到权限到模块就可以了。

这个嘛，我也没有说所有的表都要一起使用呀。用哪些表那是根据情况来定的。也就是客户需求、项目需求和经验来决定了。

如果项目很简单，客户的需求也不复杂，那么做到权限到模块就可以了，大家都方便。那么这个时候“资源表组”里面就只需要用一个表就ok了，其他的表就不用了。

如果客户的需求很挑剔，客户的使用项目的人员也很复杂，每个人可以使用的功能都很不一样，对于同一个“小模块”，添加、修改、删除等的操作也不大一样，只做到权限到模块的话，细度就不够了。那么这时候就可以根据需求来增加对应的表了。下面详细说明一下。

1、权限到模块——简单的项目，简单的需求。粒度：粗
2、权限到节点——稍微复杂一点的情况。粒度：比较粗
3、权限到节点、按钮——比较复杂的情况。粒度：细
4、权限到字段——很复杂的情况。粒度：很细
5、权限到记录——很复杂的情况。粒度：很细

权限到模块

这个就是最简单的情况了，资源表组里面只需要使用“功能节点（模块）”表就ok了。这个表里面添加的记录就是项目里面的模块的信息。做一个简单的关联就可以了。如下图：
【权限到模块的表结构图】

这时候表里面只需要记录模块就可以了，比如“人员管理”、“系统管理”、“薪金管理”等。

权限到节点

这里说的节点，就是大模块里的小模块、小小模块。就是说，不是以大模块为单位设置权限，而是以粒度更小的小小模块（节点）为单位设置权限。这样一个大模块就可以分解成许多小的模块，便于权限的灵活设置。表结构是没有变化的，只是“功能节点（模块）”表里面多记录一些记录就ok了，就是把每一个小小模块（节点）都记录进来。
这时候表里的记录可以是这样的“角色管理”、“账号管理”、“分配权限”、“登录日志”、“操作日志”等小的、详细的模块。

一个节点可以理解成一个单表的增删改查，当然了也可以是其他的情况，比如某个统计报表，某个打印功能、某个综合查询等。

权限到节点、按钮

如果把节点理解成一个单表的增删改查的话，那么有的时候不同的角色，对于同一个节点的操作权限是不一样的，比如角色A只能对该节点进行添加、修改的操作，不能进行删除的操作。角色B对该节点只能进行修改和删除的操作，不能进行添加的操作。这里只是举个例子了。就是说，虽然可以访问这个节点，但是并不能使用这个节点的全部的功能。这个时候就需要“权限到按钮”了。

我是习惯叫做“功能按钮”，当然您可也起一个其他的名字，比如说“操作”。这都无所谓了，关键在于思路对吧。

这样我们就需要增加一个表“功能按钮”（也可以叫做具体操作表）来记录一个节点有哪些功能（操作），还需要增加一个表“角色到按钮”来记录一个角色可以使用哪些功能（操作）。表结构图如下：

【权限到按钮的表关系图】

这个操作嘛，还有两种情况：死板的、灵活的。

 所谓死板的，那就是规定好了只有若干种操作，比如：查看、添加、修改、删除、打印、导出、查询、审核等。这么做的缺点就是不够灵活，如果要加点什么特殊操作的话就麻烦了。优点就是 “功能按钮”表里面只要有这么几条记录就可以了，不会有很多的记录。

 灵活的。灵活的就是每一个操作（按钮）都是独立的，只能出现在一个节点里面。这么做的缺点就是“功能按钮”表里的记录会很多，模块越多记录也就越多。优点就是很灵活，想加什么操作都可以，绝对不会影响其他的节点。

我是采用的后者，因为这样很灵活，而且把操作和按钮绑定到一起了，当然您也可以说这是紧耦合，是错误的，呵呵。

权限到字段

这里的字段分为三种情况：数据列表、查询、表单。

数据列表，就是要控制可以看到那些列（字段），不可以看到哪些列（字段）。查询就是要控制可以使用的查询条件的，表单就好理解了吧，控制表单里面显示哪些控件（字段）。

前面三种情况要增加的表不多，只有两、三个，但是如果要实现这个功能的话，增加的表就多了。当然您也可以简化，只用几个表，但是一个表里的记录就会多起来，编码的复杂度也会增加。

      这个办法的思路就是尽量的减少表的数量。如下图，只增加了四个表：“表信息”、“字段信息”、“节点里的字段”、“角色到字段”。
      其中“节点里的字段”表里面有一个Kind字段，他有三个状态：列表、查询、表单。就是通过这个字段来区分一下。可见这个表里面的记录会很多，而且需要通过Kind字段来区分。当字段不太多的时候倒是没有什么影响，不过记录多了，速度就会有一点点的影响了。
另外的一个问题就是编码的复杂程度。针对这种表设计不知道您有没有什么好主意，我是比较笨了，只想出来了一个土办法。
      比如数据列表，我们采用GridView来显示数据，那么我们就需要对GridView的每一个列做判断，判断一下到底显示还是不显示。这个每个列表页面都需要写一遍，想想都够头痛的了。针对这种数据库设计，目前我是只想出来了这么一种方法。

权限到记录

      这个也分为两种情况，一个就是列表页面里的记录；另一个就是在绑定控件（比如下拉列表框）的时候，绑定哪些数据，过滤掉哪些数据。
      列表里的记录，比如按照部门显示，按照添加人员显示，按照分类显示。这个添加一个查询条件就可以了。
      绑定控件的记录，这个可能不常见，但是实现的方式也是加一个查询条件就可以了。

如果还要做到权限到记录的话，那么就还需要再多增加两个表。

总结：

1、根据不同的需求，设置不同的表，要求越细致，表也就越多。而为了便于编码，表也就又增加了一些。
2、需要哪些表就用哪些表，用不上的表就可以删除掉嘛，这样不就没那么复杂了吗？
3、资源表组里的表，无论是增加表还是删除表，都没有影响整体结构，不知道您有没有体会到？

不知道这么说了之后，您是否理解了一些呢，是不是可以根据您的具体的需求，选用适合的表了呢？当然了，以上仅供参考。

ps：关于模块和功能节点的区别。

理论上俺是说不清楚的，还是举例子吧，就以《OnePiece 之 Asp.Net 菜鸟也来做开发（二）》这里面提到的需求为例子说明吧。（为什么用这个举例子呢？刚刚看到的，没有其他的原因）

大模块就是：所有来访者都具有的功能、会员才具有的功能、超级管理员功能、普通管理员功能。
小模块就是：分配并管理一般管理员、企业信息管理、人才招聘管理、调查问卷管理、新闻管理等。（以“超级管理员功能”为例）
小小模块是：调查项目的增删查改等功能、调查结果的统计查询、制作调查表、调查回复/评论的管理。

这个小小模块就是我说的功能节点了。