Mysql完整性约束与设计

Mysql的完整性约束

CREAT TABLE user(
id INT unsigned PRIMARY KEY AUTO_INCREMENT COMMENT'用户的主键',
    nickname varchar(50) UNIQUE NOT NULL COMMENT'用户昵称',
    age TINYINT UNSIGNED NOT NULL DEFAULT 18,
    sex ENUM('male','female');
)

主键约束

如上sql，创建表将id作为主键，令他自增，主键必须唯一，并且不为NULL

id INT unsigned PRIMARY KEY AUTO_INCREMENT COMMENT'用户的主键'

自增约束

自增约束常见于主键的自增id

AUTO_INCREMENT COMMENT'用户的主键'

唯一约束

unique，必须唯一，但允许值为空

默认约束

default，如果用户没有输入就设置一个默认值

age TINYINT UNSIGNED NOT NULL DEFAULT 18

外键约束

foreign key，两张表有关联，比如一张父表一张子表，父表某一记录删除字表也要删除，代码逻辑由mysql实现

Mysql表的设计

关系型数据库表的设计

1. 减少数据冗杂
2. 消除异常
3. 让数据组织的更加和谐
4. 范式并不是越高越好，范式越高意味着表越多，多表联合查询几率就越大

第一范式

每一列不可再分，列都是基本数据项，有原子特性，不能够再进行分割，否则设计成一对多的实体关系。例如表中的地址字段，可以再细分为省，市，区等不可再分割（即原子特性）的字段

不符合第一范式的不能成为关系型数据库

第二范式

属性完全依赖于主键，非主属性完全依赖于主关键字，如果不是完全依赖主键，应该拆分成新的实体，设计成一对多的实体关系。

例如：选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，（学号，课程名称）是联合主键，但是学分字段只和课程名称有关，和学号无关，相当于只依赖联合主键的其中一个字段，不符合第二范式。

第三范式

属性不依赖于其他非主属性，要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

示例：学生关系表为Student（学号， 姓名， 年龄， 所在学院， 学院地点， 学院电话），学号是主键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系

BC范式

每个表中只有一个候选键，简单的说，BC范式是在第三范式的基础上的一种特殊情况，即每个表中只有一个候选键（在一个数据库中每行的值都不相同，则可称为候选键），在上面第三范式的noNF表中可以看出，每一个员工的email都是唯一的（不可能两个人用同一个email），则此表不符合BC范式，对其进行BC范式化后的关系图为:

第四范式

消除表中多值依赖，简单来说，第四范式就是要消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。比如图中的noNF表中的skill技能这个字段，有的人是“java，mysql”，有的人描述的是“Java，MySQL”，这样数据就不一致了，解决办法就是将多值属性放入一个新表，所以满足第四范式的关系图如下

从上面对于数据库范式进行分解的过程中不难看出，应用的范式越高，表越多。表多会带来很多问题：

1. 查询时链接多个表，增加sql查询复杂度
2. 查询时连接多个表，降低了数据库查询性能

因此，并不是应用的范式越高越好，视实际情况而定。第三范式已经很大程度上减少了数据冗余，并且基本预防了数据插入异常，更新异常，和删除异常了

个人常用学习课程

C/C++Linux服务器开发/后台架构师

Golang DevOps项目实战