数据库规范

说明

规范：数据库规范-强制执行 行业默认的强规范将不列举在其中。若多次触犯，才考虑添加在此规范中，必要时将上线规范检查工具，强制规范检查。

字符集

规范：

• 数据表，字段统一使用 utf8mb4_unicode_ci
• 若需要区分大小写，可选使用 utf8mb4_unicode_cs
• 字符集需要(已经)全局设置，无需在 DML 中设置

不遵守的后果：

• 字符集不一致，无法使用 =（等号）操作符
• 字符集兼容度不够导致特殊字符无法存储

命名

规范：

• 表，字段命名需要望文生义，减少文档查阅
• 命名法：蛇形命名法(snake case)，示例：aaa_bbb_ccc
• 开头和结尾不允许出现 _
• 不允许出现单字母
• 避免使用 is_ 开头。此类命名可能会被 Java 反射误解
• 布尔类命名，必需使用正向含义，值将存储 1 是 0 否，避免产生误解
• 多模块系统，表名按模块统一添加前缀，前缀建议 2~4 个字母
• 字段名不建议使用前缀
• 字段名请避开 MySQL 关键字

不遵守的后果：

• 代码生成工具/框架无法准确映射为实体对象
• 首尾出现 _ 无法转换为驼峰命名法，或转换之后容易误解

基础字段

数据库字段	接口字段	含义	备注
id	id	主键	此字段必需在首位，下述的其他字段均放在表的最后
ext01	ext01	扩展字段01	扩展字段(默认情况下不需要，若存在,默认共01~10个, 不够再单独加)
sort	sort	排序	若业务逻辑无需排序时，可全局忽略此字段
create_time	createTime	创建时间	前端无需传值，后端自行维护
create_by	createBy	创建人	用户编码，前端无需传值，后端自行维护
update_time	updateTime	修改时间	前端无需传值，后端自行维护
update_by	updateBy	修改人	用户编码，前端无需传值，后端自行维护
remark	remark	备注	一般不用于控制业务，只作为数据的备注使用
version	version	版本号	乐观锁控制字段。在 update 相关接口时必传
deleted	无	逻辑删除状态	不展示给任意业务逻辑。deleted=0 表示有效，删除时填充时间戳

要点：

• 基础字段必需全局一致，其他字段不可冲突
• 布尔类型的含义，均使用正向命名: 正例: 生效状态，反例: 失效状态
• 布尔类型的含义，均使用正向值：正例: 1 是 0 否，反例: 0 是 1 否
• 作为索引的字段，必需 NOT NULL

建表语句示例

CREATE TABLE `auth_user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'ID',

  -- 以下是业务字段
  `user_code` varchar(31) NOT NULL DEFAULT '' COMMENT '用户编码',
  `username` varchar(63) NOT NULL DEFAULT '' COMMENT '用户名',
  `nickname` varchar(63) DEFAULT NULL COMMENT '昵称',
  -- 以上是业务字段

  `sort` int NOT NULL DEFAULT '0' COMMENT '排序',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `create_by` varchar(31) DEFAULT NULL COMMENT '创建人',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `update_by` varchar(31) DEFAULT NULL COMMENT '更新人',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注',
  `version` int NOT NULL DEFAULT '0' COMMENT '版本号',
  `deleted` bigint unsigned NOT NULL DEFAULT '0' COMMENT '软删除标记',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `user_code` (`user_code`) USING BTREE,
  KEY `username` (`username`) USING BTREE
) ENGINE=InnoDB COMMENT='用户';

编码 Code

字段名	字段用途	索引	说明
id	当前表的唯一标识	/	只作为单表操作的唯一标识，不能关联到其他表
xxxx_code	该条数据在整个系统级的唯一标识，用于表间关联	唯一索引	xxxx 为有业务含义的名称。不可修改。编码生成需要有技术含义
parent_code	父子关系的父节点。顶级时为 0	普通索引	非父子关系的数据，此字段不存在
xxxx_code_path	编码路径，父子关系的编码路径	/	用于权限控制等逻辑, 如 aaa/bbb/ccc
xxxx_code_show	该条数据的唯一标识，不可用于关联，仅用于展示和查询	与 deleted 字段组合后唯一	用于对外展示的唯一编码。可被修改，但不建议修改。编码生成需要有业务含义

注意：

• 避免使用类似 code 无法直接读出字段含义的命名。需要使用可读出含义的字段名
• 在没有 xxxx_code_show 编码展示需求时，尽量不要设计此字段

数据状态

字段名	字段用途	内容说明
start_time	当前数据的有效开始时间	时间仅有简单含义的数据有效期描述，使用此字段
end_time	当前数据的有效结束时间	时间仅有简单含义的数据有效期描述，使用此字段
status	当前数据的有效状态	1 有效, 0 无效。仅有简单含义的数据状态，使用此字段
xxxx_status	当前数据的业务状态	多状态: 具有业务意义的英文枚举。布尔状态: 使用 tinyint, 1 是 0 否

注意：

• 若仅需要描述数据的有效状态，不使用时间范围控制，使用 status 字段描述
• 若需要描述数据有效期，使用 start_time, end_time, status，同时使用定时任务方式驱动 status 状态变更
• 若数据有明确的业务状态含义，使用 xxxx_status 描述数据状态，内容为英文枚举，需注明对应系统中的具体枚举类型

其他规范

序号	规范名	规范说明
1	ID	必须定义主键，默认为 ID，整型自增（如果有特殊情况，可商讨后自定义）
2	外键	禁止使用外键，一切外键概念必须在应用层解决
3	小数	小数类型用 decimal（禁止使用 float 和 double），如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储
4	备注	表和字段都要有明确的注释，当定义有修改时，要及时修改注释信息
5	长度	varchar 长度设计需要根据业务实际需要进行长度控制,可适度预留，禁止预留过长空间，防止后续无法扩充字段
6	索引	积极添加索引，适时使用联合索引。索引字段必不能为 null
7	列含义	多表中的相同列，必须保证列定义一致

业务增长后的考虑方案

场景	方案
数据归档	大量冷数据场景，可使用归档方式解决数据量大的问题
分库分表	若业务数据量庞大，系统不便于拆分，同时有明确的分库/分表条件，可使用分库分表解决
更换存储方案	若数据无强事务要求，数据量庞大，需要考虑 ES, PG, Mongo 等存储方案

查询规范

• 大量数据查询，必需使用分页。数据量大到无法控制时，需要考虑 id 偏移方式翻页
• 复杂 SQL 必需 explain 评估后再执行/上线
• List 查询避免 blob、text 等字段查询

注入风险管理强制

原则：注入风险管理强制-强制

说明：防止一切注入风险：

• 【重要】orderBy 中使用 ${}。必需使用 setOrderBy 传入，已经添加风险控制
• MBG 的 noValue，singleValue，betweenValue，listValue 注入风险：Example 的 Criteria 产生，无注入风险
• MBG 的 like 注入风险：like 前的由 Example 控制，后的为 #{}，无注入风险
• 【重要】Custom 实现的 like 强制使用 AND column like concat("%",#{value},"%")