继续，这是第三章了。拖得有点长，但是我也是一边写，一边在想办法，想怎么做才能让资源权限也能通用起来。看大家的回复也给了我一些提示，我也在修改我的方案。原来打算用来解决一个人虽然在业务一部，但是却可以看业务一部、业务二部的客户信息的情况，但是仔细想了一下，这么做也不行。不过还好，我又找到了另一个方法来解决，而且可以让资源权限更加通用。不过这个详细的方法要放在下一章的角色表组里面来说明了。（这是写这篇之前的想法，写完之后想法又变了。）
通用权限想要写的文章目录：（这是第三章）
1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表（表单、查询）
9、 权限的验证
10、 资源方面的权限
11、 角色管理的程序（给客户用的）
12、 权限下放
13、 个性化设置
组织机构表组
这个简单一些，目前只有两个表。
Dept_Department，这个是n级分类的设置，对以小公司来说，可以放业务部、客户服等部门；对于集团来说可以先放分公司（比如子公司1、子公司2），然后再在下一级里面放业务部、客户服等。而对于更大的集团的话，可以先放置“西北区”、“华北区”、“华东区”这样的大区，然后再在下一级放分公司，再在下下一级放业务部、客户服。就是说一个公司不管如何去划分“部门”，总之都往这个表里面放。
| 字段名 | 中文名 | 字段类型 | 字段大小 | 默认值 | 是否为空 | 说明 |
|---|---|---|---|---|---|---|
| DepartmentID | 组织机构 | int | 4 | 1 | 0 | 主键 |
| 机构名称 | 机构名称 | nvarchar | 50 | _ | 0 | 可以是部门，也可以是分公司、地区 |
| 机构简称 | 机构简称 | nvarchar | 50 | _ | 0 | 机构简称 |
| 结构描述 | 结构描述 | nvarchar | 50 | _ | 0 | 结构描述 |
| 机构类型 | 机构类型 | nvarchar | 50 | _ | 0 | 机构类型 |
| 办公室电话 | 办公室电话 | nvarchar | 50 | _ | 0 | 办公室电话 |
| 传真 | 传真 | nvarchar | 50 | _ | 0 | 传真 |
| 邮编 | 邮编 | varchar | 6 | _ | 0 | 邮编 |
| 地址 | 地址 | nvarchar | 50 | _ | 0 | 地址 |
| 备注 | 备注 | nvarchar | 50 | _ | 0 | 备注 |
| 子机构数量 | 子机构数量 | int | 4 | 0 | 0 | 不包括子子机构 |
| 本机构员工数 | 本机构员工数 | int | 4 | 0 | 0 | 本机构（不包括子机构）的员工数 |
| 本机构全部员工数 | 本机构全部员工数 | int | 4 | 0 | 0 | 本机构和子机、子子机构的员工数量 |
| ParentID | 父节点ID | int | 4 | 1 | 0 | 父节点ID |
| ParentIDPath | 父节点ID的路径 | nvarchar | 30 | 0, | 0 | 父节点ID的路径 |
| DeptLevel | 机构层数 | int | 4 | 1 | 0 | 第几级的机构 |
| Sort | 序号 | int | 4 | 1 | 0 | 总排序 |
Dept_Department_Person，表示一个机构里面有哪些人员，机构和人员是多对多的关系。
| 字段名 | 中文名 | 字段类型 | 字段大小 | 默认值 | 是否为空 | 说明 |
|---|---|---|---|---|---|---|
| DeptPersonID | 序号 | int | 4 | 1 | 0 | 主键 |
| DepartmentID | 组织机构 | int | 4 | 1 | 0 | 外键 |
| PersonID | 人员ID | int | 4 | 1 | 0 | 外键 |
问：为什么要在权限里面加上组织机构？他和权限有什么关系呢？
答：准确的说，组织机构和操作权限基本上没有什么关系，但是却和资源权限有很大的关系。
我想用我以前做过的一个CMS项目来说明，我先简要介绍一下客户的情况。出于商业秘密原因，我说的会比较“模糊”，但是并不会影响说明组织机构和资源权限的关系。
客户是一个集团公司，集团里面有四个销售子公司，和一个售后服务公司。销售子公司都是独立运营，各卖各的产品；售后服务公司内部分为四个服务部，分别对应四个销售公司。（如下图）
Dept_Department 里的信息如下：
部门里的人员信息：
就是说一个客户购买了销售一公司的产品后，服务一部就要对这个客户进行售后服务。这样就出现了，销售一公司填写客户信息的时候，很自然的这个客户就成为了销售一公司的客户（客户的部门ID记录的是销售一公司的部门ID“3”）。然后服务一部的员工要对销售一公司的客户进行售后服务，那服务一部的员工就要可以看到销售一公司的客户（不能看到其他销售公司的客户信息）。
这就出现了一个问题，客户信息里面并没有服务一部的部门ID，那我们怎么区分呢？把服务一部的员工都放在销售一公司吗？这不就乱了吗？我当时是做了一个部门ID的对应关系，虽然可以解决，但是很显然不够通用。
这还没完，服务部又出来了一个问题，服务一部的经理可以看到服务一部的客户外，还可以看到服务二部的客户信息，而服务三部和服务四部的经理都只能看到自己的服务部的客户信息。这个倒是好办，可以把服务一部的经理放在服务一部和服务二部里面。
最后还有一个普遍的问题，那就是销售一公司的业务员只能看到自己添加的客户信息，销售公司的经理只能看到销售一公司的客户信息。
三个问题，虽然可以用许多的方式方法来解决，但是如何来统一呢，如何不用写死在代码里面呢？
问题的根本原因就在于一个人所在的部门，与可以看到的部门不一致！虽然对于第二个问题可以采用强制一致的方法，但是对于第一个问题就不行了。
我前几天的想法是这样的，在Person_User_Info表里面添加一个DepartmentIDs字段，这个字段来记录人员可以查看的部门ID，比如服务一部的售后服务工程师的DepartmentIDs 字段的内容就是：“3,8”。这样我们就是用了两个“地方”来存放人员和部门的对应关系。
但是仔细想一想，这个方法也不够完美，还是有一个问题和一个隐患。
问题：我需要知道访问页面的人是业务员、服务工程师还是经理。如果不能确认的话，就无法进行资源的过滤。
隐患：如果发生了冲突了怎么办。比如，假设服务工程师可以看到业务员修改客户信息的页面，那么服务工程师不就会因为DepartmentIDs的原因而可以修改客户信息了吗？虽然我可以不给服务工程司分配业务员的修改客户信息的页面的权限，但是我总觉得，其他的地方有可能会出现冲突的情况。
所以我就想放弃这个想法，改用角色资源的方式，这个在下一章的角色里面在说明。
在写这一篇之前还是想放弃这个方案的，但是一边写一边想，最后还是保留这个方法吧，只要能够和角色，资源角色配合好，这个方法还是可行的。
如果您想看数据库说明文档（人员、角色、组织机构、项目描述、还有上一篇里的图）的话，可以到这里下载：http://www.cnblogs.com/jyk/archive/2009/06/06/1497616.html