众望通科技 研发中心
数据库设计规范
> 拟稿：周志尧
>
> 版本号 1.0.4
>
> 1. 修改：修改数据库设计概述、行业规范、数据库命名字母大小写规范的内容描述
> 2. 新增：新增数据库命名分段命名原则的示例表
> 3. 去除：去除数据库命名长度受限原则的示例表
[TOC]
# 数据库设计概述
本设计规范只适用于关系型数据库。
## 数据库选型
#### 推荐选型
* 开源数据库
> PostgreSQL、MySQL
* 商业数据库
> Oracle
* 国产数据库
> 国家信创产品
#### 不推荐选型
> DB2、Sybase
# 命名规范
## 通用命名规范
##### Ø规范：遵循行业规范
当有相关国家/行业强制性数据结构标准规范存在时，用于存储业务数据的业务表，在表名命名上原则上应该遵从标准规定，其表中相关字段的中文名称（即数据项名称），若标准规范上有规定的应遵循规定。此外，若标准规范上对数据项的类型、长度有规定的，原则上也应当遵循或保证能直接兼容保存和访问。
##### Ø规范：字符编码规范
遵循各种数据库推荐的字符编码
| 数据库类型 | 库编码字符集 | 表编码字符集 |
| ---------- | -------------- | -------------- |
| Oracle | simple Chinese | simple Chinese |
| MySQL | utf8mb4 | utf8mb4 |
| PostgreSQL | utf-8 | utf-8 |
| DB2 | gbk | gbk |
##### Ø规范：字母大小写规范
所有数据库对象命名（库、表、字段、视图、索引）字母，遵循各种数据库推荐的大小写规范：
| 数据库类型 | 表名大小写 | 字段名大小写 | 库名大小写 | 视图名大小写 | 索引名命名规范 |
| ---------- | -------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------- | --------------------------------------------- | ---------------------------------- |
| Oracle | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 |
| MySQL | 统一使用小写 | 统一使用小写 | 统一使用小写 | 统一使用小写 |统一使用小写|
| PostgreSQL | 统一使用小写 | 统一使用小写 | 统一使用小写 | 统一使用小写 | 统一使用小写 |
| DB2 | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 |
##### Ø规范：长度受限原则
为保证将来系统跨平台的可移植性，表、视图命名长度不超过30个字符
##### Ø规范：字符范围原则
只能使用英文字母、下划线、数字进行命名，首位字符必须是英文字母。
##### Ø规范：分段命名原则
命名中多个单词间采用下划线分隔，以便阅读同时方便某些工具对数据库对象的映射。如XXX_XXX_XXX，但不限于三段式。
| 数据库类型 | 分段命名原则 | 分段命名示例 |
| ---------- | ------------ | ----------------- |
| Oracle | XXX_XXX_XXX | FOOD_BR_TASK_LIST |
| MySQL | xxx_xxx_xxx | food_br_task_list |
| PostgreSQL | xxx_xxx_xxx | food_br_task_list |
| DB2 | XXX_XXX_XXX | FOOD_BR_TASK_LIST |
##### Ø规范：勿用保留词
数据库对象命名，不能直接使用数据库保留关键字，以及Java、JavaScript等常用语言的保留关键字
##### Ø建议：同义性原则
对于同一含义尽量使用相同的单词命名，避免同一单词表示多种含义的情况，以免引起误解
##### Ø建议：命名方式一致原则
在一个系统、一个项目中尽量采用一致的命名方式，各表之间相同含义的字段，类型定义要完全相同（包括精度、默认值等）；
##### Ø建议：扩展性原则
各系统或者项目在遵循本规范的基础上，可以根据需要制定更明确的规范细则，以满足项目管理需要。如对模块进行统一命名，然后用于表名的前缀
## 库命名规范
##### Ø规范：数据库名称长度
不超过8个字符
##### Ø建议： 库命名
尽量与项目名称一致
## 表命名规范
##### Ø规范: 长度规约
表名长度不能超过30，一般不超过五个英文单词，不推荐中文拼音（特定行业规范与约定表述除外）
##### Ø规范: 分段命名规约（待进一步商议）
例如：SYS_MOUDLE_ENTITY
SYS 表示所属的系统，一个简写单词（2-5个字符）
MOUDLE 表示数据库对象模块名或者主题分类，一个简写单词（2-5个字符）
ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3个单词，用下划线连接）
##### Ø规范: 命名前缀规范（待进一步商议）
> 系统参数表 SYS_
> 用户、权限表 U_
> 系统日志表 LOG_
> 代码表
> 字典表 DT_
> 临时表 TMP_
## 字段命名规范
##### Ø规范：长度规范
字段长度不能超过20
##### Ø规范：前缀规范
列名无需使用前缀
##### Ø规范：多段式命名（待议）
列名采用多段式命名时，各单词间用下划线分隔
##### Ø建议：特定类型字段命名
日期类型字段：推荐以 DATE 结尾的名字命名
时间类型字段：推荐以 TIME 结尾的名字命名
##### Ø建议：主键列命名
为 ID 或者以 ID 为后缀进行命名，对于需要在其它表中引用的主键字段以“_ID”后缀方式命名
## 视图命名规范
##### Ø规范：前缀规范
视图的命名以V_开头
##### Ø规范：视图其它命名规范
参考表的命名规范
##### Ø建议：视图的列名
一般与基表一致，但是根据需要可以与基表的列名不同。
# 基本设计规范
## 字段设计规范
##### Ø规范：主键
主键为带横杆的UUID，主键不表示任何业务含义
##### Ø规范：公共字段
ID 编号 VARCHAT(36)
Create_Time 创建时间 TIMESTAMP --默认为系统当前时间
Update_Time 修改时间 TIMESTAMP --默认为系统当前时间
交给持久化框架完成更新，SQL不需要特别编写
##### Ø规范：时间类型
一般时间精度使用DATE，保存到秒，例如“2010-11-22 11:22:36”
高精度使用TIMESTAMP，保存小数秒，例如“2010-11-22 11:22:36.000000”
特别说明：PostgreSQL数据库的DATE类型只精确到日期，无法保存时分秒，建议使用TIMESTAMP
##### Ø规范：数字、小数类型
不得使用VACHAR等字符串类型来保存，应该使用相应精度的数字、小数类型，确保定义时有默认值
##### Ø规范：财务金额类型
财务相关的金额类，必须使用decimal类型，确保定义时有默认值
##### Ø规范：大对象字段
ORACLE: 禁止使用CLOB类型保存大文本、图片和文件
MySQL：尽量不要使用TEXT数据类型，varchar类型支持65535字节，满足大多数场景
禁止数据库中存储图片、二进制数据，使用其他方式存储（例如文件系统，数据库只保存其地址信息）
##### Ø规范：表示状态的字段（码值）
表示简单状态的字段，字段not null，根据业务要求来设置默认值（例如默认为0）
对于Boolean类型，以1代表是（true）， 0 代表否（false）
## 公共规范
##### Ø规范：冗余字段
反范式化冗余字段使用规范，考虑具体使用场景，当SQL关连查询比较频繁，或涉及到4张以上表时可考虑采用冗余字段
##### Ø规范：注释
所有表和字段都需要添加注释
表示状态的字段，注释中应该注明每一种状态的含义，例如“0：编辑中，1：审核中，2：已完成”
##### Ø规范：默认值设置
冗余字段尽可能把所有列定义为NOT NULL，定义时设置默认值
##### Ø规范：字段数限制
表的字段数不超过50个
##### Ø建议：逻辑删除标识设计
表中应有数据对应逻辑删除标识，用逻辑删除代替物理删除，标识数据是否已删除
##### Ø建议：关联字段索引设计原则
对于数据量大的情况下，建议将数据库字段中相关联字段进行索引添加，以提高相关关联查询效率
##### Ø建议：复合主键设计原则
对于部分简单的中间关联表，可设置表关联的复合主键，提高储存和索引效率，不建议使用业务相关字段作为复合主键
##### Ø建议：分区或分表设计原则
当数据量太大导致影响到查询速度或操作速度的时候，可根据实际情况进行分区或分表进行数据储存
##### Ø建议：冷热数据分离
尽量做到冷热数据分离，减小表的宽度
# 管理规范
##### DDL管理
代码表的方式，PDM的方式
##### 权限管理
分离运维账号、开发账号、系统运行账号
##### 数据字典管理
启动开发时建立数据字典，管理命名中使用的英文单词、英文单词缩写、拼音首字母缩写等，对用于命名的单词进行统一管理
##### 规范管理
DDL定义必须符合本设计规范，通过脚本校验工具（规避关键字、强制规范的校验）
# 基本理论基础
> 数据设计的三个范式 3NF
>
> 1. 表内的每一个记录都只能被表达一次；
> 2. 表内的每一个记录都应该被唯一的标识（有唯一键）；
> 3. 表内不应该存储依赖于其他键的非键信息。