权限的设计.docVIP

不管是在网站开发还是MIS系统开发中，涉及到多用户的软件系统都会遇到这个问题，如何比较优雅的解决这个问题也一直是大家经常探讨的热门话题，本文试着谈论一下自己的观点，希望和大家共同切磋。 方法一： 用户表： T_UserInfo id name 对象表: T_Object id name 权限表 T_Access accessid userid（外键，来自用户表） objectid（外键，来自对象表） access(用代码记录用户的权限组合： 1000 浏览 1100 浏览、添加 1110 浏览、添加、编辑 1111 浏览、添加、编辑、删除 等) 方法二： 用户表： T_UserInfo id name 对象表: T_Object id name access1(代表浏览，保存用户的id号，用逗号分隔) access2(代表浏览、添加) access3(代表浏览、添加、编辑) access4(代表浏览、添加、编辑、删除) 孰优孰劣？ --------------------------------------------------------------- 我們用的是第一種 WINDOWS系統用的也是第一種 --------------------------------------------------------------- 方法2不可取，用户增加的时候非常麻烦，而且access1--access4的长度很难确定。 下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。 权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。 我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。 完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。 我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。 权限表及相关内容大体可以用六个表来描述，如下： 1 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述； 2 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）； 3 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID； 4 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述； 5 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述； 6 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。 先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止） 好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。 或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例