一对一
Ø 一对一是将数据表“垂直切分”，其实是不常见，或不常用的。也就是 A 表的一条记录对应 B 表的一条记录，为什么要这样的设计呢，不是增加了程度的复杂性吗，然而并不一定，举例说明：
1) 一个系统必然有 Employee（员工表）（包含字段：EmployeeId、姓名、性别、年龄、电话、地址等），每个员工都为一个用户，所以还有张User 表（包含字段：UserId（关联 EmployeeId）、用户名、密码、角色等），这样你会发现，整合为一张表是否不太妥当？因为，User 的记录只会在登录时用到，感觉有点违背三大范式中的“确保每列都和主键列直接关联，而不是间接关联”。
2) 还有种情况，这就要根据具体的业务来决定了。如果，当一张表的字段过于太多，而很多字段可能只有在某些情况下，才会使用到，这时也可以考虑使用一对一设计。
Ø 优点
1. 便于管理、可提高一定的查询速度
2. 减轻 CPU 的 IO 读写，提高存取效率。
3. 符合数据库设计的三大范式。
4. 符合关系性数据库的特性。
Ø 缺点
1. 增加一定的复杂程度，程序中的读写难度加大。
一对多
Ø 一对多，是最常见的一种设计。就是 A 表的一条记录，对应 B 表的多条记录，且 A 的主键作为 B 表的外键。这主要看以哪张表为中心，以上示例以A 表为中心，就是一对多，如果以 B 表为中心，则是多对一。举几个例子：
1. 班级表 与 学生表，一个班级对应多个学生，或者多个学生对应一个班级。
2. 角色表 与 用户表，一个角色对应多个用户，或者多个用户对应一个角色。
3. 商品表 与 图片表，一个商品对应多张图片，或者多张图片对应一个商品。
多对多关系，需要创建一个表，表中需要两个字段，分别是引用，两个多对多字段主键的外键。
例如：
学生表（学号，姓名，…………）主键：学号
课程表（课程号，课程名，…………）主键：课程号
一个学生能选多门课，一个课可以由多个学生选，即是多对多关系，
那么成绩表就是它们之间关系的体，
即引用成绩表（学号，课程号，成绩）。这里学号和课程号，分别是学生表和课程表中学号和课程号的外键
mysql表的一对一/一对多/多对多联系
1.数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。
2.通过表的关系，来帮助我们怎样建表，建几张表。
一对一
一张表的一条记录一定只能与另外一张表的一条记录进行对应，反之亦然。
学生表：姓名，性别，年龄，身高，体重，籍贯，家庭住址，紧急联系人
其中姓名、性别、年龄、身高，体重属于常用数据，但是籍贯、住址和联系人为不常用数据
如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用
常用信息表：ID(P)，姓名，性别，年龄，身高，体重
不常用信息表：ID(P)，籍贯，家庭住址，紧急联系人
解决方案：将常用的和不常用的信息分享存储，分成两张表
不常用信息表和常用信息表，保证不常用信息表与常用信息表能够对应上：找一个具有唯一性的字段来共同连接两张表。
一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录，反之亦然。
一对多
一张表中有一条记录可以对应另外一张表中的多条记录；但是反过来，另外一张表的一条记录只能对应第一张表的一条记录，这种关系就是一对多或多对一。
母亲与孩子的关系：母亲，孩子两个实体
母亲表：M_ID(P),名字，年龄，性别
孩子表：C_ID(P),名字，年龄，性别
以上关系：一个妈妈可以在孩子表中找到多条记录（也可能是一条），但是一个孩子只能找到一个妈妈，是一种典型的一对多的关系。
但是以上设计：解决了实体的设计表问题，但是没有解决关系问题，孩子找不到母亲，母亲也找不到孩子
解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录:在孩子表中增加一个字段指向母亲表，因为孩子表的记录只能匹配到一条母亲表的记录。
母亲表：M_ID(P),名字，年龄，性别
孩子表：C_ID(P),名字，年龄，性别，母亲表ID（母亲表主键，孩子表外键）
多对多
一对表中（A）的一条记录能够对应另外一张表（B）中的多条记录；同时B表中的一条记录也能对应A表中的多条记录
老师和学生
老师表 T_ID(P),姓名，性别
学生表 S_ID(P),姓名，性别
以上设计方案：实现了实体的设计，但是没有维护实体的关系
一个老师教过多个学生，一个学生也被多个老师教过
解决方案：增加一张中间关系表
老师与学生的关系表：ID(P),T_ID,S_ID
老师表与中间表形成一对多的关系，而中间表是多表；维护了能够唯一找到一表的关系；
同样的学生表与中间表也是一个一对多的关系;
学生找老师：找出学生ID—>中间表寻找匹配记录（多条）—>老师表匹配（一条）
老师找学生：找出老师ID—>中间表寻找匹配记录（多条）—>学生表匹配（一条）
