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