这次要写一整套的权限方面的文章了，无论我的想法好与不好，先写出来请大家来评判。这个系列我要详细的说明我的权限的思路、想法、实现方式、代码和Demo。可能有人会说，通用是达不到的，最多只能无限接近。恩，对于我来说，能够无限接近就可以了，当然我知道如果要达到这个目标并不是一件容易的事情，有难度才有挑战，才有意思。所以我会在权限方面不断的努力，不断的无限接近通用。也请大家多多帮忙，毕竟一个人的力量是有限的。
通用权限想要写的文章目录：（这是第一章）
1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表（表单、查询）
9、 权限的验证
10、 资源方面的权限
11、 角色管理的程序（给客户用的）
12、 权限下放
13、 个性化设置
简介
（以下都是我的个人理解，不一定正确。如果有误请多多指正。）
1、何谓权限？
我说一下我的理解，权限从字面上看就是“权力的限制”。在软件里面，权力是什么呢？就是一种操作、一个功能点。那么在软件里面权限就可以理解为“对操作（功能）的限制”，说白了就是某人能不能做某件事情、某个操作。
2、何谓角色
角色是权限的集合，一个角色可以拥有若干的权限，一个人拥有了这个角色，那么就拥有了这个角色所拥有的权限。就是方便设置权限的一种产物。
3、何谓用户组
这个应该来自于windows操作系统吧，windows操作系统里面有用户和用户组，给一个用户组设定好权限后，用户组里面的用户就具有了用户组的权限。我觉得应该和角色是一个意思。所以我的通用权限里面只有角色，而没有用户组。
4、如何来通用？
我所说的“通用”，就是不写死在代码里面，需求有变化的时候，尽量不用修改代码就可以让客户满意。我的思路就是把权限和代码分离开来，写程序的时候不用关心权限的事情，只要“切成小片”就可以了。而设置角色的时候也不用考虑程序具体是什么样子的，或者说不会由于程序不适合而需要再去改程序。
5、权限不仅是操作，还有资源
前面说了，权限是对某个操作的限制，如果只有操作那就好办了，但是问题是除了操作之外还有资源。比如CMS里面的客户信息，业务员只能修改自己添加的客户，不能修改和查看其他人添加的客户信息；而业务一部经理可以查看业务一部的客户信息，不能查看其他业务部的客户信息；业务部的总经理可以查看全部的客户信息。业务员的可以根据UserID来过滤，而经理级别的就要用部门ID来过滤了。这就比较麻烦，如何才能把资源的权限给抽象出来呢？这个好像就不太容易了，而且这个还不是最麻烦的，更麻烦一点的是，比如张经理是业务一部的经理，但是他不仅可以查看业务一部的客户信息，而且还可以查看业务二部的客户信息，为什么呢？因为他还兼任业务二部的经理（当然还可以是其他原因）。更复杂的情况相信还有很多。
另外我刚才说的只是资源权限的一小部分，而我经历的项目不多，而且也不是很复杂，所以这方面积累的经验还远远不够，经验不够就不好抽象了。本来想去某人那里去学习点经验的，但是某种原因不想去了。所以嘛，在这里借此机会，向大家发个请求：如果您遇到了资源权限方面的需求，还请您把客户的需求告诉我，我好积累更多的经验（已知条件），好把资源权限做得更好，谢谢大家了。当然了，我想出来的办法都会写到我的blog里面的。
实现思路和数据库设计
因为我是老脑筋了，面向数据库的，所以最先想到的就是如何来设计数据库，所以下面就说一下思路和数据库。
权限涉及到的部分：人员、组织机构、项目描述、角色。其中角色是权限自己的，而人员、组织机构、项目描述则是相关联的部分。
“项目描述”是什么？
您可能会对项目描述比较陌生，这是什么东东？这个对于我来说是非常重要的，如果没有这个项目描述，我是做不到“通用”的。（注意：我是说我不用项目描述做不到通用，并不是说其他人也都做不到。）
我是喜欢使用数据库的，所以这个权限我也用数据库的形式来体现了。先画一个图来看看上面四个部分的关系。
下面是四个部分里面的表的关系。
【人员】
【角色】
【组织机构】
【项目描述】
这一章就这样结束了，没有什么具体的东东，希望没有倒大家的胃口。下一章就会介绍详细详细介绍这几个数据库，包括思路、用意和用法。争取在一周内把权限都写完。您的留言就是我的动力，谢谢！
如果您想看数据库说明文档（人员、角色、组织机构、项目描述、还有上一篇里的图）的话，可以到这里下载：http://www.cnblogs.com/jyk/archive/2009/06/06/1497616.html