当前的的crm系统中新融入了“用户组”的概念，融入“用户组”的目的是为了能通过用户组架起人员和权限之间的桥梁。实现人员和权限的间接的多对多的关系。
一、对老系统部分功能合并到新系统的疑问
疑问1：存在“部门表”和“部门字典信息”，同时新融入的“用户组”的概念，这3者肯定有重复。现在系统中用的比较多的是“负责人”选择“用户名”或“负责部门”。其中的部门就是“用户组么”？回归到起点：即“用户组”和”部门”是一个概念么？
疑问2：一个部门或用户组肯定存在“等级”的概念：“经理”和“普通员工”。所以我认为此处的“等级”就是角色的概念。“角色”可能是需要的。
疑问3：用户组表和权限表之间存在关系。那么systemlogin中存在的“User_Right”就不会再起作用了，存在就会矛盾了（暂时存在只是维持老系统不出错），是不是该删除User_Right？
总结：理不清他们的具体的关系，以及他们存在的重复性。
二、个人理解的人员、用户组、权限、角色、菜单之间的关系
说明：
1. 教师A可能属于“语文组”，也可能属于“地理组”。
2.“语文组”肯定会有“语文组组长”和“普通教师”一职，这就是“角色”。其中“语文组组长”可能只有一个人，但是“语文组普通教师”可能有多人：如教师A、教师B。（细粒度控制）。
3.“语文组”有多种权限，“语文组组长”有权限看“教师A”的提交的工作报告，也有权限看“教师B”提交的工作报告，以及批阅报告。“语文组普通教师”只能查看自己的工作报告，和批改学生的作文等操作。（细粒度控制）
总结：权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：
判断 “Who对What(Which)进行How的操作” 的逻辑表达式是否为真。
三、设计的原则
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。
细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。
设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。
需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。
举例：
人员--------------（所属用户组---角色）--------------对应的权限：说明
人员1-----------（组1-------------组长）---------------权限：批阅该组普通组员的报告。
人员1-----------（组2-------------组员）---------------权限：写报告。查看自己的报告。
人员2-----------（组1-------------组员）---------------权限：写报告。查看自己的报告。
人员3-----------（组1-------------组员）---------------权限：写报告。查看自己的报告。
人员4-----------（组2-------------组长）---------------权限：批阅该组普通组员的报告。
建议表：
人员表、用户组表、角色表、权限表、人员--组-角色表、组-角色-权限表。
