ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

2021-09-21

2021-09-21 18:29:51  阅读:115  来源: 互联网

标签:21 角色 一个 可以 09 用户 2021 模块 权限


一,前言  权限管理系统的应用者应该有三种不同性质上的使用,
A,使用权限
B,分配权限
C,授权权限 
本文只从《使用权限》和《分配权限》这两种应用层面分析,暂时不考虑《授权权限》这种。
二,初步分析 用户和角色  说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情。因此再添加一个角色表,把某些人归为一类,然后再把权限分配给角色。角色属下的用户也就拥有了权限。
用户、角色之间的关系是 一个用户可以对应多个角色,一个角色可以对应多个用户。多对多关系。
所以需要一个中间表,相信大家都很熟悉,自然不会有疑问。
应用场景  有了用户和角色以后,就需要设计应用场景,比如一个应用程序有几大模块(系统模块、项目管理模块、销售模块),
类似这样的模块就是一种应用场景,常见的还有 菜单 、 操作 等等。
假设现在我们设计好了,应用场景包括 模块、菜单、和操作,那么应该有以下六种关系

  • 一个用户可以对应多个模块,一个模块可以对应多个用户。多对多关系。
  • 一个用户可以对应多个菜单,一个菜单可以对应多个用户。多对多关系。
  • 一个用户可以对应多个操作,一个操作可以对应多个用户。多对多关系。
  • 一个角色可以对应多个模块,一个模块可以对应多个角色。多对多关系。 
  • 一个角色可以对应多个菜单,一个菜单可以对应多个角色。多对多关系。  
  • 一个角色可以对应多个操作,一个操作可以对应多个角色。多对多关系。



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

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

三,把问题简单化

不同的应用场合,你可能会想出不同的需求,提了一个新的需求以后,可能会发现原来的设计没方法实现了,于是还要添加一个新的表。这也是上面所提到的问题。  
其实不必想得那么复杂,权限可以简单描述为:
某某主体 在 某某领域 有 某某权限 

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

用户和角色:通用权限管理系统数据库表结构如何设计? - 软件系统/项目管理 - 商友论坛 商人论坛,企业管理|营销|行业商经交流 - Powered by Discuz!NT

标签:21,角色,一个,可以,09,用户,2021,模块,权限
来源: https://blog.csdn.net/zdw2xw/article/details/120404015

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有