本文共 2846 字，大约阅读时间需要 9 分钟。

目录

---

一、数据表设计（一对多，多对多）

       

做一个项目，必然是少不了数据库设计的！在学习阶段，基本都是单表。然而在实际开发过程中，一对多，多对多的表处处都是！简单整理一下，一对多，多对多表如何设计整理一下思路：

       数据库实体间有三种对应关系：一对一，一对多，多对多。

       一对一关系示例：

• 一个学生对应一个学生档案材料，或者每个人都有唯一的身份证编号。

       一对多关系示例：

• 一个学生只属于一个班，但是一个班级有多名学生。

       多对多关系示例：

• 一个学生可以选择多门课，一门课也有多名学生

 1.一对多关系处理：

       通过学生和班级问题了解一对多：

   

 

 设计数据库表：只需在 学生表 中多添加一个班级号的ID；

注：在数据库中表中初学时，还是通过添加主外键约束，避免删除数据时造成数据混乱！

 2.多对多关系处理：

    通过学生选课了解多对多问题的处理：

 

在多对多中在一个表中添加一个字段就行不通了，所以处理多对多表问题时，就要考虑建立关系表了

例：

学生表：     课程表：   关系表：

 

注：所以对于多对多表，通过关系表就建立起了两张表的联系！多对多表时建立主外键后，要先删除约束表内容再删除主表内容

二、数据库怎么设计多对多的数据表

 

1.数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。2.通过表的关系，来帮助我们怎样建表，建几张表。一对一一张表的一条记录一定只能与另外一张表的一条记录进行对应，反之亦然。3.学生表：姓名，性别，年龄，身高，体重，籍贯，家庭住址，紧急联系人其中姓名、性别、年龄、身高，体重属于常用数据，但是籍贯、住址和联系人为不常用数据如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用常用信息表：ID(P)，姓名，性别，年龄，身高，体重不常用信息表：ID(P)，籍贯，家庭住址，紧急联系人解决方案：将常用的和不常用的信息分享存储，分成两张表不常用信息表和常用信息表，保证不常用信息表与常用信息表能够对应上：找一个具有唯一性的字段来共同连接两张表。一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录，反之亦然。4.一对多		一张表中有一条记录可以对应另外一张表中的多条记录；但是反过来，另外一张表的一条记录只能对应第一张表的一条记录，这种关系就是一对多或多对一母亲与孩子的关系：母亲，孩子两个实体母亲表：ID(P),名字，年龄，性别孩子表：ID(P),名字，年龄，性别以上关系：一个妈妈可以在孩子表中找到多条记录（也可能是一条），但是一个孩子只能找到一个妈妈是一种典型的一对多的关系。但是以上设计：解决了实体的设计表问题，但是没有解决关系问题，孩子找不到母亲，母亲也找不到孩子解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录:在孩子表中增加一个字段指向母亲表，因为孩子表的记录只能匹配到一条母亲表的记录。母亲表：ID(P),名字，年龄，性别孩子表：ID(P),名字，年龄，性别，母亲表ID（母亲表主键）5.多对多一对表中（A）的一条记录能够对应另外一张表（B）中的多条记录；同时B表中的一条记录也能对应A表中的多条记录老师和学生老师表 T_ID(P),姓名，性别学生表 S_ID(P),姓名，性别以上设计方案：实现了实体的设计，但是没有维护实体的关系一个老师教过多个学生，一个学生也被多个老师教过解决方案：增加一张中间关系表老师与学生的关系表：ID(P),T_ID,S_ID 老师表与中间表形成一对多的关系，而中间表是多表；维护了能够唯一找到一表的关系；同样的学生表与中间表也是一个一对多的关系; 学生找老师：找出学生ID--->中间表寻找匹配记录（多条）--->老师表匹配（一条）老师找学生：找出老师ID--->中间表寻找匹配记录（多条）--->学生表匹配（一条）

三、多对一、多对多关系的设计——非注解伪外键

        外键只是一个约束，可以防止添加异常数据，比如外键表添加了一条数据，而主键表没有添加相关数据。 设计的时候不设置外键，可以在程序内进行约束，不会影响程序功能，但对于数据库规范来说，设计的时候最好加上外键约束

观点1：我们都知道每张数据表都有一个能够确定每行数据唯一性的字段，也就是主键。而在关系数据库中，常常有两表存在一定关系的情况。即一张表的主键跟另一张的外键存在对应关系，我们知道这种关系是存在的，那么我们在创建数据库表的时候是否一定要把外键关系约束加上呢？因为一旦创建了这个关系，在开发中就可能遇到莫名其妙的问题，所以我一般都是不设置外键关系，只设置主键约束。而两表的主外键关系在实际开发中通过程序来控制，达到数据的完整性，一致性。

观点2：外键约束毕竟是一个约束，只是保证数据完整性的一个手段。

数据库系统本身约束手段是更可靠的。 对于开发来说，可能觉得建立外键关系没必要，但是到了以后维护阶段，或升级阶段，如果没有这个关系，可能不利维护工作的提升。表关系的建立，也阐述着具体的业务逻辑关系，增加了可读性。 在逻辑性，关联性比较强的时候不妨添加。 其他时候简单的外键约束也是可以的，不需要一有关系就添加，但是要有其他机制保证数据完整性，毕竟外键对于开发有时候还是有限制。 总的来说前期开发可以不管，后期维护尽量转移到数据库本身的约束来建立关系

观点三：我一般都是不设置外键关系，只设置主键约束，而两表的主外键关系在实际开发中通过程序来控制，达到数据的完整性，一致性。当然了，具体的操作还需根据实际项目的架构来安排，对我本人来说这两种做法都无技术层面的问题。

正方观点（支持使用外键约束）：

1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。 eg：和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？  2，有主外键的可以增加ER图的可读性，这点在数据库设计时非常重要。 3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面

反方观点（反对使用外键约束））：

1，可以用或应用程序保证数据的完整性 2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题 3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert,   update,   delete   数据的时候更快） eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！  

四、多对一、多对多关系的设计——非注解真外键

 

五、多对一、多对多关系的设计——注解@manytomany

 

 

 

转载地址：http://hxnws.baihongyu.com/