mysql数据库中间表如何设计

没必要 如果企业没有这个管理项的话 在中间表里根本不会存在该企业和该管理项对应的记录，除非有一种情况，该企业有该管理项，但是启用或者不启用，这时需要加标识列，具体看实际业务是怎么样的

2，逗对于 逗N对N地 的关系，两个 Model 之间肯定是需要一张中间表的，比如 Student、Class 之间选课关系，是多对多的，肯定需要一张 Enroll 的表来维持，记录两个表的主键（Primary Key），但是不需要在数据库层加外键约束，只需要加两个索引，或作为联合主键。

3，至于查询，尽量不用 JOIN。但是问题是我确确实实是需要知道多个表的信息。

比如我要知道某门课（Class，已知 ID）的信息，同时还有选上该课（Enrolled）的学生信息（Student）。

使用 JOIN 看没问题，我相信你可以写出一个很长的 JOIN 语句。

但是，可能有的地方大概这样实现的（伪代码）：

getClassInfo(@class_id)

{ SELECt class_col1, class_col2 FROM class WHERe class.id = @class_id }

getStudentInfo(@class_id)

{ SELECt student_col1, student_col2 FROM student WHERe student.id IN (SELECt enroll.student_id FROM enroll WHERe enroll.class_id = @class_id) }

两种方案各有优缺。

后者最大的一个优点是灵活，比如我们引入缓存（Caching）。

一般来说，一个学校 class 数量不多，并且经常被查询，系统可能会引入缓存层（如 memcached、redis）来存放 class 对象。

那么上面的 getClassInfo 其实会变为

{

if(memcached.has(@class_id) != null)

{

return memcached.get(@class_id)

}

//查询数据库（只有 class 表），和上面的 SQL 一样

memcached.set(@class_id, class_object)

return class_object

}

一对多和多对一是多个表 ，至少两个表，一对多和多对一是相互的：

主键是自己定义的，一般外键表引用的对应的表的键是主键；

多对多三个表，有一个是关系表（中间表）；

中间表没有普通字段，一般只有有两个外键，同时引用两个表，多对多就出来了

2.通过表的关系，来帮助我们怎样建表，建几张表。

一对一

一张表的一条记录一定只能与另外一张表的一条记录进行对应，反之亦然。

学生表：姓名，性别，年龄，身高，体重，籍贯，家庭住址，紧急联系人

其中姓名、性别、年龄、身高，体重属于常用数据，但是籍贯、住址和联系人为不常用数据

如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用

常用信息表：ID(P)，姓名，性别，年龄，身高，体重

不常用信息表：ID(P)，籍贯，家庭住址，紧急联系人

解决方案：将常用的和不常用的信息分享存储，分成两张表

不常用信息表和常用信息表，保证不常用信息表与常用信息表能够对应上：找一个具有唯一性的

字段来共同连接两张表。

一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录，反之亦然。

一对多

一张表中有一条记录可以对应另外一张表中的多条记录；但是反过来，另外一张表的一条记录

只能对应第一张表的一条记录，这种关系就是一对多或多对一

母亲与孩子的关系：母亲，孩子两个实体

母亲表：ID(P),名字，年龄，性别

孩子表：ID(P),名字，年龄，性别

以上关系：一个妈妈可以在孩子表中找到多条记录（也可能是一条），但是一个孩子只能找到一个妈妈

是一种典型的一对多的关系。

但是以上设计：解决了实体的设计表问题，但是没有解决关系问题，孩子找不到母亲，母亲也找不到孩子

解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录:在孩子表中增加一个字段

指向母亲表，因为孩子表的记录只能匹配到一条母亲表的记录。

母亲表：ID(P),名字，年龄，性别

孩子表：ID(P),名字，年龄，性别，母亲表ID（母亲表主键）

多对多

一对表中（A）的一条记录能够对应另外一张表（B）中的多条记录；同时B表中的一条记录

也能对应A表中的多条记录

老师和学生

老师表 T_ID(P),姓名，性别

学生表 S_ID(P),姓名，性别

以上设计方案：实现了实体的设计，但是没有维护实体的关系

一个老师教过多个学生，一个学生也被多个老师教过

解决方案：增加一张中间关系表

老师与学生的关系表：ID(P),T_ID,S_ID

老师表与中间表形成一对多的关系，而中间表是多表；维护了能够唯一找到一表的关系；

同样的学生表与中间表也是一个一对多的关系

学生找老师：找出学生ID--->中间表寻找匹配记录（多条）--->老师表匹配（一条）

老师找学生：找出老师ID--->中间表寻找匹配记录（多条）--->学生表匹配（一条）

你的问题可能是这样的，每一种物料只有一条数据，而每个供应商也只有一条数据，怎么也无法建立出一对多的关系。如果增加一个关联字段，也只能关联到一条数据，这样的做法一般适用于一对一的关系。

我有个解决方案，不用修改你现在的两个表的设计，新建一个“中介”的中间表。这个中间表两个或三个字段（如果是三个字段，有一个字段是自增加的Key）。主要的两个字段就是物料表的key和供应商表的key，这样，每种物料对应多少供应商，全部插入到这个中间表里面。物料表或者供应商表的数据只要没有新的数据加入，就可以不用去改它们。实际上，这种设计还可以应用到权限角色管理上，比如一个User对应多个角色Role，而在User表，每个人一条数据就够了，而不是去增加只有角色不同的User数据，在执行查询操作的时候，也会引起逻辑混乱。

从你的描述中，可以看出 “演员”与“电影”的关系是“多对多”

1、“多对多”的关系，必须要产生一个“中间表”，用来保存他们的连接关系。

2、“中间表”用来保存他们的连接关系，也方便了日后的更改，如果有连接关系变动，直接修改“中间表”即可。

（你可以从我的图很容易的理解，希望可以帮助你！）

然后管理员发布消息，就发布到消息表中，然后用户登录，查看用户表消息表和中间表关连查询，如果没有数据，则说明未读，然后把中间表的关联加入，说明已读。这样只有中间表的数据比较多，但是中间表的数据字段就少很多！

这种多对多关系一般也会利用中间表实现！

仅供参考！

数据库设计的基本步骤：

1、系统需求分析与设计。

2、概念结构分析与设计。

3、逻辑结构分析与设计。

4、物理结构分析与设计。

5、系统实施。

6、系统维护。

扩展资料：

数据库设计技巧：

1、原始文件与实体的关系

它可以是一对一，一对多，多对多的关系。一般来说，它们是一对一的关系：一个原始文档只对应于一个实体。在特殊情况下，它们可以是一对多或多对一关系，即一个原始文档对应于多个实体，或者多个原始文档对应于一个实体。

这里的实体可以理解为基本表。在对应关系明确后，对输入接口的设计非常有利。

2、主键和外键

一般来说，实体不能既没有主键也没有外键。在E－R图中，叶中的实体可以定义主键或不定义主键（因为它没有子代），但它必须有外键（因为它有父项）。

主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库的设计完成后，一位美国数据库设计专家说：“钥匙无处不在，只有钥匙。”。这是他数据库设计的经验，也体现了他对信息系统核心（数据模型）高度抽象的理念。

因为：主键是一个高度抽象的实体。主键和外键的配对表示实体之间的连接。

3、基本表的属性

基本表不同于中间表和临时表，因为它具有以下四个特点：

原子性。基本表中的字段不可分解。

原始主义。基本表中的记录是原始数据（基本数据）的记录。

演绎的。所有输出数据都可以从基本表和代码表中的数据导出。

稳定。基本表的结构比较稳定，表中的记录要长期保存。

在了解基本表的性质之后，在设计数据库时，可以将基本表与中间表和临时表区分开来。

参考资料来源：百度百科-数据库设计