首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 数据库 > SQL Server >

权限数据库设计有关问题

2012-12-23 
权限数据库设计问题我要设计一个数据库要求:用户至少要有5种,对每个设备的操作有20种,设备至少要有15个。后

权限数据库设计问题
我要设计一个数据库要求:
用户至少要有5种,对每个设备的操作有20种,设备至少要有15个。后期还有可能添加设备或是每个设备的操作,或是用户种类

我设计如下:
用户表
User_id     User_name    User_(其他属性,如邮箱,地址,联系方式等等)
1           User1           张三@qq.com
2           User2           李四@qq.com
...

设备表
Equip_id   Equip_name   Equip_description
1          Equip1       用于监视的设备
2          Equip2       用于操作的设备
...
权限表
Right_id   Right_name   Right_description
1          a            操作1
2          b            操作2
...

用户设备权限表
ID         User_name    Equip_name       Right
1          User1        Equip1           abc(即拥有a,b,c三种权限)
2          User1        Equip2           ab
3          User2        Equip1           a
4          User2        Equip2           b
...

感觉最后一个表会很复杂。不知道遇到这种情况的话要怎么做呢。。。期待~~




[解决办法]
最后一个表不是复杂的问题,是违背了设计泛式1NF,第一原则:原子不可分性。
多对多的关系,需要一个中间表,防止出现需要拆分字符串abc这种现象。
还有,外键一定要用数字Id,不要User_name  ,Equip_name 这样使用varchar类型做关联,因为会产生歧义,可能同时有两个同名的人或设备。
这是数据库设计的第3泛式3NF,唯一关联性(只和主键关联)

所以你最后一个表应该这样设计,前几个表都没问题

用户设备权限表 ,这个表的ID用途不大,主要是3个外键起作用。
ID        User_Id    Equip_Id     RightId 
xx          1           1           1
xx          1           1           2
xx          1           1           3
这样三条记录,就代表abc,即拥有a,b,c三种权限
[解决办法]
做个多对多的表吧

本人设计的一般是用户表,模块表,权限对应表(用户对应表,怎删改查个一列BIT类型,来判断权限)
[解决办法]
顺便,每次设计数据库的时候默念3个泛式:
1NF:原子不可分性,就是每个字段不可以拆分,比如1,2,3或者你的abc这样的设计就违反了。需要把字段拆成多行记录
2NF:主键关联性,每个表所有字段必须依赖于主键。
3NF:只和主键关联性,表和表之间只依靠主键关联,表的其他字段之间不互相依赖。

以上3条,我是用自己的语言整理的,希望你也用自己的话来整理。
我一般浓缩成3个词:
不可分,关联,非关联
或者
原子,依赖,不依赖
------解决方案--------------------


我工作12年,其中权限系统几乎是每个大中型项目必须的,所以我已经驾轻就熟,已经不把它当回事了。

我设计权限的惯例是:
1,用户表(字典表)
2,角色表(字典表)
3,拥护角色表(关系表)
4,功能表(字典表)
5,角色功能表(关系表)

这里边包括2个关系表,如果简单的系统可以不分角色
1,用户表(字典表)
2,功能表(字典表)
3,用户功能表(关系表)

但是一般系统都是比较复杂,而且加一个角色可以把用户分组,方便授权操作。
因为用户是大量的,功能是大量的,所以把用户利用角色来分组,授权的界面就是给用户加到某一组或多组(赋予角色),而角色和权限早就规划好了。
就简单多了。
如果再复杂的系统,就把功能也分组或者树状功能菜单。

所谓权限就是控制用户看到哪个菜单(功能)。
[解决办法]
数据库里的表,你可以分成2大种。
1,字典表(有一个主键)
2,关系表(有2个以上的数字外键)

有些表具有2中特点,那么有时候他是作为字典表使用,有时候是作为关系表使用的。
比如定单,就是记录用户和产品的关系的关系表,同时定单也是有编号和其他字段的字典表。
当查用户买了什么产品的时候,他是关系表。
当根据单号来查看其他字段的时候,他是字典表。

这样你可以迅速的设计或读懂别人的设计。
也可以马上看出设计的问题。
[解决办法]
狼就是厉害。。。。学习了。。。不过权限基本是每个项目必备的。。。写一个,其他的拿来用就OK了
[解决办法]
学习。。。我要好好学习一下。。。。。。。。。。
[解决办法]
不过这样一来最后一个表岂不是会很复杂?
[解决办法]
学习了
[解决办法]
多对多的关系,习惯就不觉得复杂了。

ID        User_Id    Equip_Id    RightId 
xx          1          1          1 
xx          1          1          2 
xx          1          1          3 

通过3行记录,达到你原先设计的一行记录的目的
ID        User_name    Equip_name      Right 
1          User1        Equip1          abc(即拥有a,b,c三种权限) 

在具体编程时候,符合规范的设计,会带来很大方便。

权限设计这个算是简单的了。
我还整理了一些更复杂的,见下文。
 
[解决办法]
数据库设计多对多关系的几种形态 
前言:多对多关系至少需要3个表,我们把一个表叫做主表,一个叫做关系表,另外一个叫做字典表或者副表(字典表是纪录比较少,而且基本稳定的,例如:版块名称;副表是内容比较多,内容变化的,例如)。 
按照数据库的增删查改操作,多对多关系的查找都可以用inner join或者select * from 主表 where id in (select 主表id from 关系表) 

1,角色任命型 

特点:关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键,有一个表是字典类型的表。 
界面特点:显示主表,用checkbox或多选select设置多选关系。 
例如:任命版主(用户表-关系表-版块名称表),角色权限控制等,用户是5个版块版主,只要关系表5行纪录就可以确立,关系表的两个外键具有联合主键性质。 
增加关系:如果没有组合纪录,insert之。 
删除关系:如果有组合纪录,删除之。 

2,集合分组型 

特点:同角色任命型类似,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。区别是主副表都不是字典表,可能都很大不固定。 
界面特点:显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。 
例如:歌曲专集(专集表-关系表-歌曲表)。手机分组(分组表-关系表-手机表)。用户圈子(圈子表-关系表-用户表)。文章标签(文章表-关系表-标签表) 
增加关系:同版主任命型。 
删除关系:同版主任命型。 


3,明细帐型 

特点:关系表可以有重复纪录,关系表一般有时间字段,有主键,可能还有文字型的字段用来说明每次发生关系的原因(消费)。 
界面特点:显示关系表,用radio或下拉设置单选关系。 
例如:现金消费明细帐或订单(用户表-订单表-消费原因表),用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。 
增加关系:不管有没有组合纪录,insert之,纪录时间。 
删除关系:根据关系表PK删除。 


4,评论回复型 

特点:同明细帐型关系表一般有时间字段,有主键,区别是重点在文字型的字段用来说明每次发生关系的内容(评论回复)。 
界面特点:回复文本框。 
例如:论坛回复(用户表-回复表-帖子表),用户可能多次在不同帖子上评论回复费。 


增加关系:不管有没有组合纪录,insert之,纪录时间和文字。 
删除关系:根据关系表(回复表)PK删除。 

5,站内短信型 

特点:主副表是同一个,关系表一般有时间字段,有主键,重点在关系表文字型的字段用来说明每次发生关系的内容(消息)或者其他标记位来表示文字已读状态时间等。 
界面特点:回复文本框。 
例如:站内短信(用户表-短信表-用户表),用户可能给用户群发或者单发,有标记位来表示文字已读状态时间等。 
增加关系:不管有没有组合纪录,insert之,纪录时间和文字。 
删除关系:根据关系表(回复表)PK删除。 

6,用户好友型 

特点:主副表是同一个,同集合分组型,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。 
界面特点:同集合分组型,显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。 
例如:下载站点的文件,(文件表-关系表-文件表)可以被软件工具打开,软件工具本身也是一种文件,可以被下载。用户的好友,也是用户(用户表-好友关系表-用户表) 
增加关系:同版主任命型。 
删除关系:同版主任命型。 


7,未知属性型 

特点:在设计初期,主表的某些字段类型和名称是不确定的时候,关系表实际上是主表的可扩展字段, 
一个[主表](ID), 
一个[属性名称表](属性ID.属性名称), 
一个[属性值表],包括3个字段: 
      属性值(属性Value varchar(500)) 
      主表ID 
      属性ID 

这样可以作到最小冗余度。 
(和常见的多对多关系不同的是:值统一用varchar来存储,因为这类型的值一般不会用来计算)。 

比如: 

军队的数据库设计中有种物资叫做“战缴物资”,就是打仗的时候缴获的,军队自己都不知道这些物资有什么属性。 

比如缴获的化学品有化学名,通用名,是否有辐射,计量单位,包装规格,数量等等,或者不是化学品是其他任何未知的东西。 
这样东西就可以 

某奇怪东西.属性集合["某某奇怪属性名"]="某某奇怪值";  
某变态东西.属性集合["某某变态属性名"]="某某变态值";  

这样存储。 

再比如: 

手机型号有几千种,除了共同属性外还有不同属性有几百个,属性名和值类型都不一样,有的手机有这属性,有的没有。 
对于这样的“多态”,我们就采用上面的设计结构。 
其效果相当于: 

某奇怪手机.属性集合["某某奇怪属性名"]="某某奇怪值"; 
某变态手机.属性集合["某某变态属性名"]="某某变态值"; 

界面特点:设置主表一行纪录的属性时候,要列出所有可能的属性名称,每个对应一个文本框。 

[解决办法]
如果你在上海,可以到我这里参观一下,有些东西打字是不好展示的。
我们设计完数据库是出图的,图比较大,一个系统可能有100多个表。
还有就是保密,不能随便把图发到外网上,但是到现场看一下是可以的。
[解决办法]
学习。。。
[解决办法]
狼,太强大了
[解决办法]

引用:
如果你在上海,可以到我这里参观一下,有些东西打字是不好展示的。
我们设计完数据库是出图的,图比较大,一个系统可能有100多个表。
还有就是保密,不能随便把图发到外网上,但是到现场看一下是可以的。

狼你好强大啊,你们公司还要人不?我去跟你混吧
[解决办法]
的撒旦<html>
fdsfdsfds
</html>
[解决办法]
太叼了  。   
[解决办法]
狼,你太牛了!受益匪浅啊...
[解决办法]
学习呀
[解决办法]
牛人!
[解决办法]
狼,好强。
[解决办法]
我们最近在做一个小项目,我就要设计个权限管理系统,看到你的讲解,我的思路清晰多了 
狼 ,你太强了 
学习了
[解决办法]

--我觉得一般啊,这些算简单的。

[解决办法]
都是牛人啊
[解决办法]
up
[解决办法]
狼,太佩服你了....
基础要打扎实,补习一下先
[解决办法]
是啊,数据库一定要基本功
------解决方案--------------------


引用:
我工作12年,其中权限系统几乎是每个大中型项目必须的,所以我已经驾轻就熟,已经不把它当回事了。 

我设计权限的惯例是: 
1,用户表(字典表) 
2,角色表(字典表) 
3,拥护角色表(关系表) 
4,功能表(字典表) 
5,角色功能表(关系表) 

这里边包括2个关系表,如果简单的系统可以不分角色 
1,用户表(字典表) 
2,功能表(字典表) 
3,用户功能表(关系表) 

但是一般系统都是比较复杂,而且加一个…


lz可以看看sqlserver数据库的权限管理,类似我引用的这个仁兄写的。
[解决办法]
学习了

[解决办法]
支持,很好
[解决办法]
学习。。。我要好好学习一下。。。。。。。。。。
[解决办法]
好厉害!我得好好学习学习
[解决办法]
kan kan
[解决办法]
学习!
[解决办法]
受教了
[解决办法]
hao 
[解决办法]
很艱很強大!
[解决办法]
偷牛人经验
[解决办法]
...
[解决办法]
```````````````````````````````````````````
[解决办法]
顶,进来看看
[解决办法]
领教了!也不得不感叹“狼”你太强了
[解决办法]
正学SQL,经常遇到点小麻烦;值得学习,的确基础很重要,要不后面会因为前面的问题很难做下去。
[解决办法]
mark
[解决办法]
确实不错,个人认为角色,叫权限组比较合适,有的项目里面真的就有角色,容易混淆
[解决办法]
好好学习一下!
[解决办法]
学习!
[解决办法]
帮顶
[解决办法]
路过
[解决办法]
很好!很强大!对新人来说很有帮助!
[解决办法]
学习下  www.tg68.cn我搞的网站  希望大家给点建议
[解决办法]
   牛人太多!
[解决办法]
学习
[解决办法]
学习。
[解决办法]
确实很好,讲的很透彻,如果够每个例子加一个设计出来的数据库脚本的话就成为经典学习案例了
[解决办法]
管理了多个ERP系统 。
这里看到有好的权限分配方法。
[解决办法]
这帖子不能沉了。。。帮顶!!!
[解决办法]
进,你的数据库表设计得很好,受教了
------解决方案--------------------


用户权限是通用的,设计一个数据库如下:


[解决办法]
up
[解决办法]
强人啊
[解决办法]
....
[解决办法]
这样的贴子得天天看 才能领悟...
[解决办法]
三张表,两两多对多关系,产生两张中间表,总共五张表。
[解决办法]
巩固巩固
[解决办法]
太精辟了,受益非且
[解决办法]
膜拜一下 “狼”。受益匪浅呀!!!
[解决办法]
感谢superdullwolf  我也受益匪浅~~~
[解决办法]
又学到了!
[解决办法]
我设计这个表只用了五张,用户,角色,权限,角色权限,角色用户

热点排行