权限管理设计------之数据库设计

一,前言

权限管理系统的应用者应该有三种不同性质上的使用,

A,使用权限

B,分配权限

C,授权权限

本文只从《使用权限》和《分配权限》这两种应用层面分析,暂时不考虑《授权权限》这种。

二,初步分析

用户和角色

说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表。这样就决定了一个人有什么样的权限。

做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情。因此再添加一个角色表,把某些人归为一类,然后再把权限分配给角色。角色属下的用户也就拥有了权限。

用户、角色之间的关系是一个用户可以对应多个角色,一个角色可以对应多个用户。多对多关系。

所以需要一个中间表,相信大家都很熟悉,自然不会有疑问。

应用场景

有了用户和角色以后,就需要设计应用场景,比如一个应用程序有几大模块(系统模块、项目管理模块、销售模块),

类似这样的模块就是一种应用场景,常见的还有 菜单 、 操作 等等。

假设现在我们设计好了,应用场景包括 模块、菜单、和操作,那么应该有以下六种关系

  1. 一个用户可以对应多个模块,一个模块可以对应多个用户。多对多关系。
  2. 一个用户可以对应多个菜单,一个菜单可以对应多个用户。多对多关系。
  3. 一个用户可以对应多个操作,一个操作可以对应多个用户。多对多关系。
  4. 一个角色可以对应多个模块,一个模块可以对应多个角色。多对多关系。
  5. 一个角色可以对应多个菜单,一个菜单可以对应多个角色。多对多关系。
  6. 一个角色可以对应多个操作,一个操作可以对应多个角色。多对多关系。

于是建立六张表来维护这六种关系。

这样设计看起来没什么问题。是的,如果没有加入新的关系的话,这样是已经可以满足大部分的需求了。可是如果就是如果,新的关系(需求)往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。

可以看出,这样的设计有几个问题:

  1. 数据表设计太复杂
  2. 应对系统方案过于固定

三,把问题简单化

不同的应用场合,你可能会想出不同的需求,提了一个新的需求以后,可能会发现原来的设计没方法实现了,于是还要添加一个新的表。这也是上面所提到的问题。

其实不必想得那么复杂,权限可以简单描述为:

某某主体 在 某某领域 有 某某权限

1,主体可以是用户,可以是角色,也可以是一个部门

2, 领域可以是一个模块,可以是一个页面,也可以是页面上的按钮

3, 权限可以是“可见”,可以是“只读”,也可以是“可用”(如按钮可以点击)

其实就是Who、What、How的问题

因此上面所提到的六张表其实可以设计一张表:

四,实例说明

下面用一个例子做设计说明。“用户、角色在页面上的是使用权限”

详细设计:

1,把菜单的配置放在数据库上,每一个菜单对于一个唯一的编码MenuNo,每一个“叶节点”的菜单项对于一个页面(url)。

2,把按钮的配置放在数据库上,并归属于一个菜单项上(其实就是挂在某一个页面上)。应该一个页面可能会有几个按钮组,比如说有两个列表,这两个列表都需要有“增加、修改、删除”。所以需要增加一个按钮分组的字段来区分。

3,把菜单权限分配给用户/角色,PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Menu",PrivilegeAccessValue为MenuNo,PrivilegeOperation为"enabled"

4,把按钮权限分配给用户/角色,PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Button",PrivilegeAccessValue为BtnID,PrivilegeOperation为"enabled"

5,如果需要禁止单个用户的权限,PrivilegeOperation 设置为"disabled"。

如果不清楚的可以看下图:

数据库设计:

四,结语

说了这么多,其实我推荐的只是Privilege的表设计。这个表是who、what、how问题原型的设计。不仅扩展性、灵活性都很好,而且将复杂的权限管理系统浓缩成一句话。

而PrivilegeOperation不仅仅只是使用和禁止两种,包括分配权限、授权权限,都可以用这个字段定义。只是这无疑加大了应用程序的设计难度,但是对于表设计可以不做出任何的修改就可以完成,可以看出其灵活性。

原文地址:https://www.cnblogs.com/xiaoqi58585945/p/9324795.html

时间: 2024-11-09 22:13:19

权限管理设计------之数据库设计的相关文章

ASP.NET MVC+EF框架+EasyUI实现权限管理系列(2)-数据库访问层的设计Demo

原文:ASP.NET MVC+EF框架+EasyUI实现权限管理系列(2)-数据库访问层的设计Demo ASP.NET MVC+EF框架+EasyUI实现权限管系列 (开篇) (1)框架搭建 前言:这篇博客我们继续来实现我的权限系列,这个博客一段时间也没有写了,重点是我在想还写不写,最终我决定还是写下去,因为我们是为了学习,当别人提出意见的时候,我们可以参考和采纳,但是我们不一定非要采纳,上几篇博客大家都说用CodeFirst来实现,是啊,现在基本很少有人用我的这种方法来实现了,都是用CodeF

知识管理系列---2.数据库设计

系列引导: 知识管理系列----1.原型设计 知识管理系列----2.数据库设计 前言: 数据库的设计是整个数据架构最核心的部分. 详细设计部分: 此数据库设计为V1.0版本,后续开发过程中会进行版本迭代. 数据库创建SQL脚本:SQL脚本 原文地址:https://www.cnblogs.com/xiaowangzi1987/p/8456020.html

选课系统的界面设计、类图设计、数据库设计

一.界面设计 不论学生.老师登陆界面统一是下图,根据输入的用户名来判断该进入哪种界面. 学生登陆后的界面: 教师界面:教师登陆后到课程名称界面,选择课程后得到第二张图. 二.类图设计 三.数据库设计 课程:课程编号,开课系别,教师编号,时间,教师,容量,先决条件 教师:教师编号,教师姓名,教师性别,所属学院 学生:学生编号,开课学院,学生专业 教授课程:课程编号,教师编号 上课信息:学生编号,课程编号,上课时间,教室

【软件工程】02组软件工程组队项目——课程管理小助手数据库设计文档

一.引言 1.1编写目的 数据库的表结构设计是整个项目开发中一个非常重要的环节,一个良好的数据库设计,可以提高开发效率,方便系统维护,并且为以后项目功能的扩展留下余地.我们通过书写这份文档说明,从各方面进行学生课程管理小助手系统的数据库设计规划,用它指导该系统在数据库各方面的内容,为系统开发的程序员.系统分析员提供基准文档.我们也希望通过写数据设计说明书,规范数据名称.数据范围.数据代码等.这份文档是项目小组共同作战的基础,有了开发规范.程序模块之间和项目成员之间的接口规则.数据方式,大家就有了

sql数据库设计学习---数据库设计规范化的五个要求

http://blog.csdn.net/taijianyu/article/details/5945490 一:表中应该避免可为空的列: 二:表不应该有重复的值或者列: 三: 表中记录应该有一个唯一的标识符  在数据库表设计的时候,数据库管理员应该养成一个好习惯,用一个ID号来 唯一的标识行记录,而不要通过名字.编号等字段来对纪录进行区分.每个表都应该有一个ID列,任何两个记录都不可以共享同一个ID值.另外,这个ID值最 好有数据库来进行自动管理,而不要把这个任务给前台应用程序.否则的话,很容

以一个权限系统来告别WebForm —(一)项目整休架构设计与数据库设计

在本节我想与大家与分享一下,我所将要做的权限系统的架构和数据库的表的设计.请各位大神们对我项目中设计的不足之处进行指导,让我得以更好的写完它,留给需要它的人. 我的项目架构如下图所示: 如上图所示,在数据访问层,我采用了抽象工厂的方式,来对数据访问层和业务逻辑层解耦,当然如果你想更高大上一些,可以用第三方的框架,比如Spring.Net ,Autofac来实现.解耦的好处在于可以方便的切换数据库,当数据库变更时,只需换一下对应的数据访问DAL就行,本系列中,我所采用的是SQLServer.写到这

学员管理示例:数据库设计

原文地址:https://www.cnblogs.com/jintian/p/11167429.html

权限管理中的数据库存储过程

1.根据用户读取相关权限 CREATE PROCEDURE [dbo].[GetRoleAction]@UserGUID uniqueidentifier,@DepartmentGUID uniqueidentifierASBEGIN    IF @UserGUID='f425ba38-df44-45d0-a9bb-f5c904bfee1c'        BEGIN            SELECT a.GUID,a.ControllerName,a.ActionName FROM Acti

学生成绩数据库设计 二 数据库设计

数据库表关系图 数据库脚本建表脚本 1 /*学生表*/ 2 CREATE TABLE Student 3 ( 4 StuNO NVARCHAR(12) NOT NULL PRIMARY KEY,/*学号*/ 5 StuName nvarchar(20) not null,/*姓名*/ 6 StuState int not null default(1),/*学籍状态.1:在读:2:试读:3:退学:*/ 7 StuJoinYear int /*入学年份*/ 8 ) 9 /*学年表*/ 10 CRE