1 命名规范
1.1数据库命名基本原则
- 所有命名采用26个英文大小写字母和0－9这十个自然数，加上下划线_组成。不能出现其他字符（注释除外）。
- 长度不超过30个字符。
- 实际名字尽量描述实体的内容，由英文单词、单词组合或单词缩写组成，不以数字和_开头。
- 命名中禁止使用SQL关键字。
- 对象名尽量短。
1.2 表命名规范
约定：表名由前缀和实际名字组成。好的名称能够容易分便表的作用
- 实体表（切切实实存数据的）：t_xxx_xxx
- 关系表(存表与表之间的关系的)：ref_xxx_xxx
- 字典表：dic_xxx_xxx
注意事项：
- 各种类型的表的开头是一致的
- 表名要见名知意，不同单词间用"_"连接
表名应该符合以下规范：
- 统一采用单数形式，反对xxxs
- 首字母大写，多个单词的话，单词首字母大写，类似驼峰命名。
- 避免中文拼音
- 避免下划线连接，反对User_Accout（下划线适用Oracle数据库）
- 避免名称过长
- 表以单数形式名词或名词短语命名。如果表名仅有一个单词，那么建议不使用缩写，而是用完整的单词。
1.3 字段命名规范
字段由表的简称，实际名字组组成。如果此字段关联另外的字段，那么加下划线_连接关联表字段的字段名。
必有字段
每个表都必须有下面的这些字段：
- id （bigint unsigned）
- creator（varchar(32) ）创建人
- updater（varchar(32)）更新人
- create_time（datetime）创建时间
- modifed_time（datetime）修改时间
- del_flag（int unsigned）删除标志
- version:数据记录的版本号，用于乐观锁，非必须
字段应该符合以下规范：
- 首个字母小写，多个单词的话，单词首字母大写
- 必须有一主键，主键不直接用ID，而是表名+ID，如userID/orderID
- 常用的字段name，不直接用name，而是表名+Name，如userName/orderName
- 常用的字段desc，不直接用desc，而是表名+Desc，如userDesc/orderDesc
- 大写字母前必须包含至少两个小写的字母
- 避免中文拼音
- 避免下划线连接
- 避免名称过长
- 避免保留字
时间的类型选择
对于MySQL来说，主要有date、datetime、time、timestamp 和 year。
- date ：表示的日期值, 格式yyyy-mm-dd,范围1000-01-01 到 9999-12-31，3字节
- time ：表示的时间值，格式 hh:mm:ss，范围-838:59:59 到 838:59:59，3字节
- datetime：表示的日期时间值，格式yyyy-mm-dd hh:mm:ss，范围1000-01-01 00:00:00到9999-12-31 23:59:59```,8字节，跟时区无关
- timestamp：表示的时间戳值，格式为yyyymmddhhmmss，范围1970-01-01 00:00:01到2038-01-19 03:14:07，4字节，跟时区有关
- year：年份值，格式为yyyy。范围1901到2155，1字节
- 推荐优先使用datetime类型来保存日期和时间，因为存储范围更大，且跟时区无关。
其他注意事项
- varchar的长度一般设置为32就够了，不用设置为255，除非特别长的情况，不然不设置为255
- 尽可能选择存储空间小的字段类型，就好像数字类型的，从tinyint,smallint,int,bigint从左往右开始选择
- 小数类型如金额，则选择decimal,禁止使用float 和double
- varchar是可变长字符串一般设置为32就够了，不用设置为255，除非特别长的情况，长度不要超过5000。
- 如果存储的值太大，建议字段类型修改为text,同时抽出单独一张表，用主键与之对应
- 同一表中，所有varchar字段的长度加起来，不能大于65535,如果有这样的需求，请使用text/longtext类型
- 所有的字段都必须为非空字段，也就是说你要设置默认值
对象：
- 主键索引以PK_为前缀
- 唯一索引以UK_为前缀
- 索引以IDX_为前缀
- 前缀后的首字母大写，多个单词的话，单词首字母大写，如PK_xxxID
- 所有的关键字的所有字母必须大写，如SELECT userID,username FROM User
- 采用有意义的字段名，应该是易于理解，能表达字段功能的英文单词或单词缩写，一般不超过三个英文单词。
- 系统中所有属于内码的字段（仅用于表示唯一性和程序内部用到的标识性字段），名称取为：ID。
- 系统中属于是业务范围内的编号的字段，其代表一定的业务信息，字段建议命名为CODE，其数据类型为VARCHAR，该字段需加唯一索引。
- 字段名不要与表名重复
1.4 SQL语句命名规范
2 设计范式
约定：所有SQL关键词全部大写。
不需要严格遵守3nf，通过业务字段冗余来减少表关联
- 第一范式：对属性的原子性，要求属性具有原子性，不可再分解
- 第二范式：对记录的唯一性，要求除了主键以外的其他列，都依赖与该主键
- 第三范式：确保每列都和主键列直接相关,而不是间接相关)是要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
我们设计表及其字段之间的关系，应尽量满足第三范式，但是有时候，可以适当冗余，来提高效率，比如如下张表
| 商品名称 | 商品型号 | 单价 | 数量 | 总价 |
| 华为手机 | p60 | 3000 | 5 | 15000 |
以上这张表存放商品信息的基本表，总价这个字段的存在，表明该表的设计不满足第三范式，因为总金额可以由单价*数量得到，说明总金额是冗余字段，但是，增加总金额这个冗余字段，可以提高查询统计速度，这就是以空间换时间的方法。
3 1：N关系的设计、
日常开发中，1对多的关系应该是非常常见的。比如一个班级有多个学生，一个部门有多个员工等等。这种的建表原则就是：在从表（N的这一方）创建一个字段，以字段作为外键指向主表（1的这一方）的主键。
学生表是多（N）的一方，会有个字段保存班级表的主键。当然，一般不加外键约束哈，只是单纯保存这个关系而已。（不搞外键关联，一般都在代码维护）
有时候两张表存在N:N关系时，我们应该消除这种关系。通过增加第三张表，把N:N修改为两个 1:N。比如图书和读者，是一个典型的多对多的关系。一本书可以被多个读者借，一个读者又可以借多本书。我们就可以设计一个借书表，包含图书表的主键，以及读者的主键，以及借还标记等字段。
