################
最大的痛点莫过于找人，有问题找人会消耗掉至少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】； |
###############
###############