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

 

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

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

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

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

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

 

权限到模块

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

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

权限到节点

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

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

权限到节点、按钮

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

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

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

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

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

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

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

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

 

权限到字段

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

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

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

 

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

 

权限到记录

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

 

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

总结:

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

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

 

 

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

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

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

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

时间: 2024-07-31 06:37:41

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

【自然框架】通用权限的视频演示(一):添加角色,权限到功能节点和按钮

      写了几个关于权限的东东,好像大家都不大理解,也不太清楚我的权限到底能做什么,所以想来想去还是弄点视频吧,就是屏幕录像,这样大家看起来就方便了吧.       为了大家便于观看视频,我先说一下视频的步骤.      1.添加角色,选择角色可以使用的功能节点和按钮.      2.选择用户,就是给角色里面添加用户.      3.用用户的账号登录,查看效果.      4.修改角色可以使用的按钮,查看效果.       这里举了一个很简单的例子--新闻维护,有两个角色,一个是"新闻维护&

【自然框架】CMS之数据库设计

    在园子里也混了三年多,随笔200多,一开始只是想把自己的经验写一下,后来呢弄出来了一个"自然框架",主要精力就放在了介绍自然框架的思路上面了.随笔多了就发现一个问题:有点乱.虽然博客有分组,但是只支持一级分组,不支持n级的.博客里也没有"栏目"这一类的设置.所以对于随笔的管理有有点力不从心了.有些兄弟看到我的博客,看到我说自然框架,然后就会很迷茫,自然框架到底是什么?能做什么?如果想看看的话,从什么地方开始看,按照什么顺序来看?   博客的这种形式就不大好解

数据库建模-业务系统系统权限数据库设计问题

问题描述 业务系统系统权限数据库设计问题 本人菜鸟,最近公司正在准备一个新项目,在权限部分的数据库设计上出现了问题. 之前框架的权限部分是基于角色的权限管理,角色与模块和操作多对多关联,关联信息存在中间表里,但是这样做会使中间表数据量非常大,每次登录都去关联各个表查询. 现在还有一个新的方法,就是取消掉模块和操作表,取而代之的是把各个角色的模块和操作权限直接用一条JSON保存到角色表的字段里,这样每次登录只查询角色表把权限JSON拿到后台处理就行了,查询速度是快了,但是如果模块和操作变动的时候就

从零开始编写自己的C#框架(9)——数据库设计与创建

原文:从零开始编写自己的C#框架(9)--数据库设计与创建 对于千万级与百万级数据库设计是有所区别的,由于本项目是基于中小型软件开发框架来设计,记录量相对会比较少,所以数据库设计时考虑的角度是:与开发相结合:空间换性能:空间换开发效率:减少null异常......当然不同的公司与项目要求不同,初学者要学会适应不同的项目开发要求,使用本框架开发时,必须严格按照本章节的要求来设计数据库,不然可能会产生不可控的异常.   从零开始编写自己的C#框架 数据库设计规范   文件状态: [√] 草稿 [ 

【自然框架】元数据的数据库结构的详细说明和示例(三):项目与数据库字段的关联

  [自然框架]PowerDesigner 格式的元数据的表结构 [自然框架]元数据的数据库结构的详细说明和示例(一):项目描述部分 [自然框架]元数据的数据库结构的详细说明和示例(二):数据库描述部分     1.Manage_FunListCol(列表用字段) 字段名 中文名 类型 大小 默认值 说明 FunctionID 节点ID int 4 1 外键,关联节点 ColumnID 字段ID int 4 1 外键,关联字段 Sort 排序 int 4 1 同一节点下的排序 ColWidth

通用权限管理设计 之功能权限

一,前言  权限管理系统的应用者应该有三种不同性质上的使用, A,使用权限 B,分配权限 C,授权权限  本文只从<使用权限>和<分配权限>这两种应用层面分析,暂时不考虑<授权权限>这种. 二,初步分析 用户和角色  说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表.这样就决定了一个人有什么样的权限. 做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情.因此再添加一个角色表,把某些人归为一类,然后再

通用权限管理设计篇(一)

一.引言 因为做过的一些系统的权限管理的功能虽然在逐步完善,但总有些不尽人意的地方,总想抽个时间来 更好的思考一下权限系统的设计. 权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限进行设 计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的权限系 统是很有意义的. 二.设计目标 设计一个灵活.通用.方便的权限管理系统. 在这个系统中,我们需要对系统的所有资源进行权限控制,那么系统中的资源包括哪些呢?我们可以 把这些资源简单概括为

复杂系统中的用户权限数据库设计解决方案_数据库其它

B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个"非法用户"很可能就能通过浏览器轻易访问到B/S系统中的所有功能.因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的"非法用户"将会将他们彻底的"拒之门外&

通用权限管理设计篇(二)——数据库设计

理清了对象关系之后,让我们接着来进行数据库的设计.在数据库建模时,对于N对N的 关系,一般需 要加入一个关联表来表示关联的两者的关系.初步估计一下,本系统至少需要十张表,分别为:权限表. 用户表.角色表.组表.用户权限关联表.用 户角色关联表.角色权限关联表.组权限关联表.组角色 关联表.用户属组关联表.当然还可能引出一些相关的表.下面让我们在PowerDesigner中画出各表吧. 各表及其关系如下: 1.用户表 用户表(TUser) 字段名称 字段 类型 备注 记录标识 tu_id bigi