微服务分布式下数据库表设计

数据库表设计存储位置的设计
在微服中项目中一个项目可能有多个项目，每个项目模块都有自己的功能职责，比如有核心业务服务，有配置服务，有web查询服务等等，我们在建立业务表的时候，每个业务表虽说有自己的具体的业务功能，应该是归类为某个服务，但是有些表确实是模棱两可的，归类为某个项目好像都是可以的。这个时候我们就要考虑微服务架构下建表的特性了，一般来说，尽量要避免事务，毕竟事务的代价不小，尽量将业务关联度某些业务属性的表放到一个库中，方便一些操作，比如关联，查询等。

比如配置服务，将人员、警力针对检查站业务来说都是配置表，可以将这些检查站类的配置表都归结为检查站的配置服务中。

2.考虑根据业务一致性特点考虑

2.1 跨服务跨表的分页查询难度大于跨表的分页查询。

考虑业务关联度，将一个业务类的表放到一个库中。在微服务中，一些关联、事务的操作代价是比较大的。这样在建立表的时候，尽量将表建立在一个库中，方便相关操作。比如班组表可以建立在配置服务中，也可以建立在web服务中。虽然建立在web服务中离用户更近方便查询，避免微服务间调用，操作更方便。建立班组的时候领导的名称肯定是来源于配置服务的警力表。但是 班组表有根据 领导名称进行查询，和班组名称查询的查询条件。如果建立在web 查询服务中，班组名称来源于web服务，警力名称来源于配置服务，在列表查询的时候，分页情况就不好处理。跨服务跨表的分页查询难度大于跨表的分页查询。

2.2 考虑表之间的业务字段参照关系

比如，警力人员姓名和班组中的警力人员姓名关系，要求保持业务上的一致性问题，业务上的一致性主要表现在查询的时候，警力表修改后，班组表也要求显示修改后的值。如警力人员的姓名/警力类型的变化，在班组中参照的警力人员姓名/警力人员类型也会要进行修改变化。
这样一般只有三种操作解决

1. 需求上变化，用户修改完姓名/警力类型后，新建立的班组的警力人员会变化，已经班组的警力人员姓名/警力类型不会变化。（班组存储警力类型、证件号、人员姓名）。
2. 交互上变化，做参照校验。如果警力人员已经编组，要求已经编警力组的人员也跟着变化，则可以在配置服务警力人员变化的时候做校验，检查人员是否已经编组，如果已经编组，则提示从班组中删除人员，才能变更人员。（班组存储警力类型、证件号、人员姓名）。
3. 需求交互不变，数据库设计做变化。 可以建立班组和警力只有主键的参照，这样在班组列表查询的时候，会根据主键去查询警力人员的姓名和人员类型。警力表的人员姓名、证件类型变化，自然在班组查询的时候会变化。（班组只存警力主键）
4. 需求交互不变，程序设计上做变化。在警力人员变化的时候，事件通知班组中人员、警力字段也跟随变化。（班组只存警力主键）

这四种情况面对的四种不同的需求/交互，需要开发人员在需求/设计阶段要考虑到具体的业务需求和交互情况做出合理的功能设计。如果在班组列表查询，查询条件中需要根据班组人员姓名查询、班组名称进行分页查询，那么在交互需求均可变化的情况下，尽量将警力人员姓名也存在班组中，毕竟在一个表的中的分页查询难度小于在两个表中的分页查询；

2.3 考虑表之间的业务字段参照存储取舍

如果班组表中值显示班组名称、警力类型、不显示证件类型的话，在班组表中可以不存储证件类型，如果在班组中也需要显示证件类型或者在查询条件中需要根据证件类型查询班组的话，那么在班组存储的时候把证件类型存储下；

比如检查站勤务业务和检查站的排班业务，检查勤务是上级给下级下发指令，一般上级给下级下发指令后就不会更改，所以再对勤务的排班中检查站的勤务相关的业务字段就不会；

2.4 根据业务特点考虑数据的历史数据与现在、未来的数据（数据的变化与不变化 ），业务表业务删除、编辑的校验；

如警力、班组、排班表中。排班表会显示排班班组名称、人员姓名、排班名称、排班日期等；

1. 已执行的排班属于历史数据，从业务上讲，不能因为班组人员变化、班组变化导致已经执行过排班的人员信息、班组信息再次查看跟谁变化（这些数据数据历史数据，不应该跟随变化），已经执行中的排班人员班组和待执行的排班、班组人员信息也不能跟随变化。所以排班表在设计的时候需要将班组、人员相关的信息需要存储下，不做参照变化。

2. 如果要求排班中待执行和执行的警力人员需要警力人员信息保持业务一致性，则需要在警力人员修改删除的时候在排班中进行业务校验，如果有警力人员正在执行排班或者有待执行排班则提示先删除 排班；同样班组和警力人员之间的业务一直性也是同样的考虑。