微服务数据库设计规范

1 文档介绍

1.1 文档目的

本文主要描述的是关系型数据库的设计规范，为数据库设计的使用人员提供设计和评审的依据，使用关系型数据库进行设计时需严格遵守本规范的相关约定，建立统一规范的数据模型。

1.2 文档范围

此数据库设计规范适用于微服务数据库设计。 

1.3 读者对象

包括数据库设计人员、数据库设计评审人员和其他质量管理人员。

1.4 参考文献

微服务一期 数据库设计

1.5 术语与缩写解释

第三范式

设计原则

  参照以下原则进行数据库设计：
- 规范性：一般符合第三范式范式要求，减少冗余数据；
- 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求；
- 紧凑性：例如能用varchar(10)的就不要用varchar(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性；
- 易用性：数据库设计清晰易用，用户和开发人员均能容易地理解；

3 一致性（统一性）

 - 对于同含义的实体或属性名，英文缩写要求一致。
- 表命名和列命名 应遵循公司标准或项目最佳实践，以增强人们对系统间信息交换和共享的理解。
- 列排序：尽量遵循统一的规则，比如最前面是标识符、名称，最后面是创建日期、修改日期等等。
- 在多个表中冗余的字段应保持命名的一致性。不同名称之间应有较明显的区别，避免混淆和误操作。

4 完整性

  概念数据模型包含实体、属性、关系三部分:
- 实体：包括能够被清楚辨识的事物,如用户、员工、班级等；或者需要固化的流程类信息，如任务流（需要记录一次任务完成的时点和出入口）；或者等待人工或系统处理的操作类信息，如投诉等；或者计算类信息，例如针对订单的一次计算，此时计算结果需要作为一个实体保存下来。
- 关系：2个实体间的关联，基于双方1个字段或者多个字段，存在一对一，一对多，多对一，多对多几种关系。当实体间关系较复杂时，可把关系当成一个实体，例如映射表和路由表。
- 属性：实体具有的属性。一个实体可以由若干个属性描述。例如用户实体有一个用户名、身份证号、出生日期等特性。
- 数据模型要充分体现这三要素。

5 范式与冗余

  设计时，尽量遵循第三范式，消除数据冗余、更新异常、插入异常和删除异常。
但为了满足部分查询效率，通常可以将常用字段在相关表中作冗余。
例如：用户表（主表）的姓名字段经常出现在其它模块的查询界面中，姓名这个字段就可以在相关模块的表（子表）中做冗余。当主表更新该属性时，应及时将子表冗余的属性进行更新，以保证冗余信息的准确性。

6 命名规则

- 表命名 : UcUser 首字母大写+驼峰 系统编码+表名；
- 列命名：userId 首字母小写+驼峰 表名+字段名；
- 字段和表名都不能有下划线；
- 驼峰只驼结构不驼语义；
- 暂不许有2次驼峰；
- 关系表、子表用复合词，例如：UcUserrole 用户角色；
- 所有词汇要精准、统一 ；

7 字段注释规则

 对于具有枚举值的字段，在设计工具中需要使用标准格式标示(不允许有空格或其他符号)
中文含义(枚举值1:枚举值名称1;枚举值2:枚举值名称2)
例：用户类型(S:学生;A:代理商;I:内部用户;T:外部教师)。

8 其它

为了系统的长期建设（性能优化、纵向拆分），建议建设时遵循以下约定：
- 禁用存储过程、触发器、Job、外键等；
- 禁用特性SQL，差异性通过框架适配；
- 数据类型仅限：varchar,char,longtext,double,int,long；
- 字段不做默认值、非空限制 ；
- 数据库结构特性是静态的，应留有扩充余地，使系统容易改变；

9 通用字段命名

- 主键：表名+年月日+节点序号+10位数据 例： USER20190101010000000001；
- 主键名称：表名+Id varchar(36)；
- 日期类型：yyyy-MM-dd HH:mm:ss char(19)；
- 状态类数据: 后缀加Status char(1)，使用相应英文缩写的大写形式表示；
- 树状结构：采用层级编码和同层排序两个字段，十位为一级 例：00000000010000000001 ；
- 创建人：表名+Creator；
- 创建时间：表名+Createddate；
- 修改人：表名+Modifier；
- 修改时间：表名+Modifieddate；
- 编码：表名+Code；

10 索引的设计

 - 多列索引需要满足左前缀原则；
- 尽量选择区分度高的列作为索引（区分度越高，我们扫描的记录就越少）；
- 索引列不能参与计算（索引列一旦参与函数计算，会使得索引失效）；
- 尽量扩展索引，不要新建索引；
- 理想的索引：1.查询频繁 2. 区分度高 3. 长度小 4.尽量能覆盖常用的查询字段；

11 安全性设计

  提高软件系统的安全性应该从"设计"和"管理"两方面入手。这里仅考虑用户中心数据库的安全性设计。
（一）防止用户直接操作数据库
用户只能用账号登录到应用软件，通过应用软件访问数据库，而没有其他途径操作数据库。对不同类型的账号设置不同的角色，根据业务要求对不同的角色设计不同的权限。
（二）用户账号密码的加密
对用户账号的密码进行加密，在任何地方都不会出现密码的明文。
（三）防止sql注入攻击
禁止单引号、左尖括号等特殊字符进入数据库。

12 优化结构设计

在应用系统的开发过程中， 经常出现修改数据库表结构的情况，有时甚至在应用系统上线运行后还会提出修改数据库表结构的要求。 按照现有的数据库设计方法，一旦系统上线运行后，提出增减某个数据库表的字段是非常困难的。 除了可能会导致数据库表结构混乱外，还会可能大量地修改程序代码，使得软件质量下降。

12.1添加预留字段的设计方法

  这种数据库表设计方式具有一定的扩展性，但是灵活性很差 ，而且会浪费一定的空间。

12.2元属性表的数据库设计方案 

这种方式的扩展性很强， 在需要添加一个属性时，只要在元属性表中添加一条记录即可，具体的属
性值存储在属性表中。但是此方案每个查询都要访问三个数据库表，在实际应用中应该折中考虑。

12.2.1元属性表方向

详细分析具体的业务， 将相对稳定的属性信息按照传统的设计方式放在主表中，如用户姓名、用户手机号，可能变化的属性按照另外两种方式进行扩展性设计，如用户品牌。 

12.2.2传统设计方向

仍然用传统的设计方式，但是在数据库表中设计一个"其他"属性字段，该字段专门用于保存需要扩充
的信息。如用户求学经历、用户工作经历，在应用系统中开发一个组件专门来解析这个字段信息