今天是星期六，经理要求在项目（医疗项目）期间由双休改为单休日，啥也不说了。
今天开会讨论了关于数据库中表的设计和关联关系的问题，而我所做的模块就是CRM模块中用户管理，预约模块，领导查询模块，后台管理模块等。其中讨论最激烈的一个模块就是用户管理中，对于系统的功能的使用和用户角色，和用户三者之间的划分问题。
因为我们要做的这个项目是根据用户权限的不同，提供相应的服务如：挂号预约，VIP服务，人工服务等系统功能，不同的用户登录系统之后根据用户角色（也就是用户权限，可以这样理解）的不同来享受相应的服务。
我的设计思路是：建立一张用户User表和一个用户权限表Right表，User表和Right表之间通过Right表的RightID来进行一对一关联，这样也就确定一个用户对应一个权限，这样在实现时就可以根据用户的权限来判断用户是否有权限来使用该系统功能。我想这也是一般大家都是这样认为的。
但是现在要变化，一个用户要有多个权限，比如，一个人既可以是项目中保健信息的维护人员也可以是人工服务人员（人工服务：包含电话，语音等）。或者说：系统的这个用户角色只能够查询，另一个用户只能去修改和更新，而另一个用户既可以查询也可以修改和删除。这样一变化，原来设计的表就感觉不能满足要求了。
从而在Right权限表进行了修改，添加了一个RightLevel字段来进行权限级别的划分，分为1，2，3等级。我想这样差不多就能解决呢，可是想在实现时你要对一个功能的使用进行权限的判断时，先是通过RightID来判断用户能够使用该模块，对于该模块中的子模块就像我前面说的查询，添加，删除等再进行RightLevel的判断。可是，这样也有缺陷，你要是系统管理员呢，那么多子模块难道要都要添加记录，你也可能说是可以给系统管理员一个最高级用户权限。
但是这样到后面进行扩展时就有很多局限性了，而且我们这个系统不是只针对一家用户使用的，要和原有的HS系统结合在一起就会麻烦重重了。而且院方一般希望系统管理人员对于角色权限的设定可以根据系统功能来确定，比如：客户服务人员(人工服务人员)只可以进行这一模块的功能，领导只可以查询各个模块的信息，不能添加或者修改，而网站信息人员可以对网站信息进行更新的权限。
最后，解决办法就是，建立一个系统操作与用户角色的关联表tb_r_Operate_Actor，即是把这里的权限表改为角色表，每个角色关联相应的系统中的各种操作，即也需要建立所有系统中功能操作的一个操作表Operate，它和角色表之间是多对多关联，所以这里在它们之间建立一个关联表。而系统中每个操作在Operate表中都是一条固定不变的记录。当然这种做法有利有弊，前提是你系统的功能操作是一定的，不能太多，不然在实现时会比较麻烦，对于每个操作都要进行判断。但是这样换来了系统的课扩展性。
上面是针对我们这个项目而言的，希望在这里总结一下，和大家探讨！