代码改变世界

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

2009-08-22 10:58  金色海洋(jyk)  阅读(7518)  评论(21编辑  收藏  举报

 

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

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

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

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

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

 


权限到模块

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




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



权限到节点

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

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



权限到节点、按钮

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

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

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

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






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

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

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

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

 

权限到字段

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

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

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

 

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

 


权限到记录

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

 

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






总结:

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

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

 

 

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

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

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

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

2