内部系统中的关系模型

最近在做的内部系统,因为关系模型问题已经纠结了很久了。公司的性质比较特殊,需求也比较的交叉繁杂,建立起一套完善的体系来,绝对是一件比较让人纠结的事情。

需求源自于目前我们业务的一部分,举个例子说项目与人的关系吧。

一、基础模式

通常来说,一个项目的信息,是由AE部门创建的,比如报价、服务内容等信息,均是由AE部门同时来完成的,每位AE只能看到自己创建或者管理的项目,每个客户组有一位Leader管理,可以查看本组的项目。

那么,其模型应该是这样的:

 

二、跨人员模式

要求来了,部分比较大的项目,一个AE无法对其完善服务,此时需要指定2-3名AE人员,那么上面的人员就有问题了,从权限上来看,A看得见B就看不见,B看得见A就看不见,那么我们就要按如下方式扩展模型

此模型,断开了S(Staff)和P(Project)的直接关联,创建了一个单独的表Relation来单独管理S和P之间的关系,RelationType用来表示关联类型,比如C(Create)、B(Belong)、A(Assistant),这样一来,每个成员都可以通过自己所拥有的权限来对项目进行管理。

 

三、跨部门模式

上一个模型,基本了更多一点的要求,但是新的需求又来了,客户群总监可以管理多个客服部门;部分项目没有AE,直接由销售接入,PM部门进行项目的信息导入等,那么上一种模型,就又不合适了。因此又产生了下面的一套模型。

根据需求,又创建了一个名为CrossManage的表格,来管理跨部门的关联,其中S(StaffID)表示成员编号,D(DepartmentID)表示该成员可以跨越管理的部门;同时去除了Staff表中的IsMaster字段,对于本部门的领导,可以在CrossManage表中创建自身与所在部门的关联。

 

经过再三考虑,暂时确定了以上的模型关联,接下来是要实践以上模型的正确性,过程中还需要不断的修正改善。

我在这里,期待着目标的实现。

 

posted @ 2013-09-13 18:47  雨帝夜泪  阅读(537)  评论(0编辑  收藏  举报