通用的权限管理系统的设计

今天无意中在首页中看到了四海同志的一篇《实现业务系统中的用户权限管理--设计篇》文章写的非常的好，里面的一些话似乎被其它权限管理系统的设计转来转去，看上去都有种似曾相识的感觉，当然，也不排除那些文章最初是由四海同志写的，后来被他们转来转去的。四海同志的文章我仔细看了下，算是看懂了吧。分析的挺透彻。我以前在b/s的权限管理系统上研究过一段时间，有些小心得，来跟大家分享下，限于我个人能力，如果写的不好，或哪里说的不对，还望朋友们指出来，千万不要拍我。

四海同志的文章中有这样一句话：“传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能"。似乎他的那个权限设计也没有能够解决资源重用的问题。当然，如果它把资源文件分别存放在不通的文件夹中，通过url来根据权限来判断那就另当别论了。

我这个人比较懒，总是想用一个通用的方法，放在哪里都合适，因此在数据库的设计上费了一番脑筋了。其实，很多的权限管理系统都不太一样，因此，很多开发者开发出来的权限管理系统放在别的地方，就不一定合适了，往往需要重新开发，权限管理系统的结构不能变，变的仅仅是数据。在这样的一个思想的指导下，我们就想法让我们的结构不要变，尽可能的通用，其实结构在哪里，还是体现在数据库上了。四海同志说：“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。

而我却认为，一个完整的权限管理系统应该包括：用户、角色、模块、资源这四个部分，在数据库的表设计上，这四张表叫做权限管理系统的实体表，只要把这四个实体表做出来，权限管理系统的架构就搭建完整了，这样的权限管理系统翻译成中文那就是：权限管理系统是判断（可能用判断这个词不是很准确）用户或角色对什么资源是否有什么功能的这样一个系统。这样设计出来的权限管理系统通用性、扩展性才够强，系统足够完整。四张实体表做好了，就意味着架构搭建好了，那么逻辑关系怎么办呢？我当时设计的时候用另外的4张表来存储他们之间的逻辑关系，总共8张表，四张实体表，四张逻辑关系表。 其它的权限管理系统可能少于8张表，一般通用性不会太好的。通常都是在完整的基础上做了下变化，有的利用继承来做，有的利用位运算，还有的虽然不通用，但是也是充分利用了自身的特点，一般都会少于8张表，但是一般翻译成汉语都不完整。通常为：用户对资源是否有什么功能、用户或角色对资源是否有权限等等。。。。切记，通用的权限管理系统无论是用户、角色、模块、资源哪个方面，都可以在不改变架构的条件下去动态的扩展，改变的仅仅是数据，而只要有这个思想，再结合自身项目的特点，相信设计和开发各种各样不通的权限管理系统不会有问题的。
受大家建议，附图一张，如下所示：

转自：http://www.cnblogs.com/wlb/archive/2008/12/12/1353752.html