反人类设计是如何炼成的?
################
最大的痛点莫过于找人,有问题找人会消耗掉至少40%的时间,首先必须基于一个事实,那就是dba和开发人员都是流动,不是不变的,而是一定会变动的,那么该如何设计才符合双方找人方便呢?
当前的问题是dba负责数据库的开发负责人和开发组长的维护,这等于是自找麻烦,dba能知晓开发人员的人员流动情况?典型的反人类设计。这本该是开发人员自己维护的,非要强加给自己,导致找个人跟大海捞针一样难。
dba平台不仅要满足业务开发人员的基本功能需求,还需要满足双方对接,比如某业务线P组有甲乙丙三人组成,甲为组长,dba组有A、B、C、D四人组成,A为组长。一般而言,组长有点权力相对稳定一点。
一个集群:必须有一个dba组长,必须有一个dba负责人,其中dba组长可以和dba负责人相同,这样的好处是,方便开发人员有问题找对应的dba;一个集群必须有业务开发人员组长列表,
一个数据库:必须属于某个集群,必须有一个业务开发负责人
一个数据库连接:
那么现在业务线P组的丙需要dba给其创建两个数据库,一个数据库需要新创建一个集群clusterM,一个数据库要创建在已有集群clusterN上,其中该业务线的dba、负责人为D,如何设计?
一个集群可以对应多个数据库,而多个数据库可能对应多个业务线,因此一个集群可能并不属于一个业务线,可能对应多个业务线,应该尽量避免一个集群有,因此一个集群应该提供一个并列的业务线负责人组长,这样就将业务线开发人员与dba平台联系起来,每个数据库连接也必须有开发人员负责人
开发组长也可能负责有个数据库,dba组长也可能负责某个集群,一个集群只有一个dba负责,可以是dba组长,也可以是dba其他成员,一个集群有多个业务线组长负责,一个数据库连接可能是业务线组长负责,也可能是业务线其他开发人员负责
现在考虑人员流动情况:
1)业务线P组开发人员丙离职或转岗;那么dba平台就应该有一个提供业务开发人员的所负责的数据库操作界面,包含查询开发人员当前负责哪些集群上的哪些数据库连接,可以更新这些数据库连接的开发人员,不可删除,除非该数据库下线,可以新增。一个事务搞定。
2)业务线P组的组长甲离职或转岗;提供集群级别的和数据库级别的查询,因为组长可能也会负责数据库级别的。提供集群级别的开发负责人更新。不提供删除。这样就能完成业务交接问题。一个事务搞定。
3)dba组的D离职或转岗;提供dba负责的集群展示和查询,提供dba负责的集群级别的更新,不提供删除。
4)dba组的组长A离职或转岗;提供dba负责的集群展示和查询,提供dba负责的集群级别的更新,不提供删除。
集群 | 一个集群对应一个dba组长【1:1】;主要作用是方便研发人员或研发新人找人 一个集群对应一个dba负责人【1:1】; 一个集群对应多个研发组长【1:1...N】; |
数据库 | 一个数据库对应一个dba负责人【1:1】;一个集群只属于一个dba负责人,必然一个数据库只属于一个dba负责人 一个数据库对应一个研发负责人【1:1】; 一个数据对应多个数据库连接1:1...N】;数据库与数据库连接是多对多关系 |
kingshared | 可以不考虑,与数据库连接一一对应 |
数据库连接 | 1)一个数据库连接对应多个数据库,即一个连接有多个数据库的权限【1:1...N】; 2)一个数据库连接必须对应一个研发负责人员列表【1:1...N】 3)一个数据库连接必须对应一个dba负责人【1:1...N】 |
研发负责人 | 一个研发负责人对应多个数据库连接 |
研发组长 | 一个dba人员对应多个集群【1:0...N】; |
dba负责人 | 一个dba人员对应多个集群【1:0...N】; |
dba组长 | 一个dba组长对应一个集群【1:1】; |
###############
###############