一、字段设计规范

（1）主键不能只是bigint，应该是bigint unsigned

阿里的《JAVA开发手册》强制要求MySQL表的主键应为bigint unsigned类型

如此强制要求的原因和MySQL索引底层使用B+树有关，具体原因可以参考另外一篇博客(3条消息) 从B+树的角度聊一聊为什么阿里的《JAVA开发手册》强制要求mysql表的主键应为bigint unsigned类型_nrsc的博客-CSDN博客

（2） varchar的默认长度应设置为32，不要使用255（除非确定了字段长度很长）

（3）所有的字段都必须非空，要设置默认值，字符型的默认值为一个空字符值串，数字型的默认值为数值0

（4）所有的逻辑删除都要是软删除（可以设计一个用于标记删除的字段，正常情况下值为1，被删除时置为0），这是为了具有可回溯性

二、命名规则

（1）无论是表名还是字段名，都只能由数字、小写字母、下划线组成

（2）禁止出现数字开头，禁止两个下划线中间只出现数字

       命名案例如下：

       正例：getter_admin，task_config，level3_name

       反例：GetterAdmin，taskConfig，level_3_name

三、尽量满足第三范式

第一范式：关系中的每个属性都不可再分

如下就不符合第一范式

应当改为

第二范式：在满足第一范式的基础上，满足所有非主属性完全依赖于码

（学生，课程）--确定--> 老师

（学生，课程）--确定--> 教材

（学生，课程）--确定--> 教室

因此（学生，课程）是一个码

老师、教材、教师都是非主属性

单独通过学生或单独通过课程，都不能确定老师（因为一个学生可能有很多个老师：语文老师、数学老师、英语老师...；一门课也会有多个老师任教），这样我们就说 老师（非主属性）完全依赖于 学生，课程（码）

同样的，单独通过学生或单独通过课程，也不能确定教室，教师（非主属性）完全依赖于 学生，课程（码）

但是，单独通过课程就能确定教材，不满足 课程这一非主属性完全依赖于码

这会造成 插入异常、删除异常、修改异常

插入异常：比如现在新增一门课程A，对应教材A，但学生此时还没有选课，那我们就没有办法把这条新课程的数据保存到表中

删除异常：比如到下学期的时候，语文课程的教材会从《语文教材（上）》改为《语文教材（下）》，这就造成了语文课上学期的教材就被覆盖了，以后要查看语文课上学期用什么教材就无法知道了

修改异常：如果那天语文教材从《语文教材（上）》换成《新语文教材（上）》，那就需要将所有的语文课的记录修改掉，修改的数据量过大

所以，问了避免上面三个异常，我们就需要将表设计为 第二范式

表1：

表2：

第三范式：在满足第二范式的基础上，消除非主属性对于候选码的传递函数依赖

看下面的表

该表是不存在非主属性对码的部分依赖的，单独的学生或课程都不能确定老师或教师职称，也就是满足 第二范式

但是（学生，课程） --确定--> （老师），同时 （老师） --确定--> （教师职称）

即 （学生，课程） --确定--> （老师） --确定--> （教师职称）

所以就存在 非主属性对于候选码的传递函数依赖，不满足 第三范式

不满足 第三范式，同样会 插入异常、删除异常、修改异常

包括 解决的办法也跟第二范式的解决办法类似

表1：

表2：