是否所有关系数据库设计都需要联结表或关联表来实现多对多关系？答案

【问题标题】：Do all relational database designs require a junction or associative table for many-to-many relationship?是否所有关系数据库设计都需要联结表或关联表来实现多对多关系？
【发布时间】：2016-01-02 01:24:42
【问题描述】：

我是数据库新手，并试图了解为什么在创建多对多关系时需要联结表或关联表。

我在 Stackoverflow 和其他地方发现的大部分内容都以高度技术性的关系理论术语来描述，或者只是被描述为“这就是它的完成方式”而没有说明原因。

是否有任何关系数据库设计支持在不使用关联表的情况下建立多对多关系？例如，为什么不可能在表上有一列保存与另一列的关系，反之亦然。

例如，一个包含课程列表的课程表和一个包含大量学生信息的学生表——每门课程可以有很多学生，每个学生可以参加很多课程。

为什么不能在任一表（可能为 csv 格式）的每一行上都有一列，其中包含与列表中其他列表或类似内容的关系？

【问题讨论】：

您似乎是通过 ORM 被介绍给数据库的，这使事情变得不必要地复杂。看我的回答。
你说得对，我最初是被介绍给 Peewee 的，现在正在尝试熟悉 SQLAlchemy。

标签： database database-design relational-database relational

【解决方案1】：

在关系数据库中，每行中没有列包含多个值。因此，您永远不会将数据以“CSV 格式”（或任何其他多值系统）存储在关系数据库的单个列中。也不允许创建包含相同项目（Course1、Course2、Course3 等）实例的重复列。这是关系数据库设计的第一条规则，被称为第一范式。

这些规则的存在是有充分理由的（验证、约束和查询数据非常容易），但无论您是否相信这些规则的好处，这些规则仍然是其中的一部分关系数据库的定义。

【讨论】：

有可能解决这个限制，但基本上这只是一个糟糕的想法？ stackoverflow.com/questions/3070384/…
这不是“绕过”“约束”，而是违反原则。没有什么可以阻止您将逗号分隔值的“列表”填充到文本列中，就像没有什么可以阻止您为程序中的每个变量和函数提供一个从 unicode 的某些难以理解的部分中选择的单字符名称字符集。但我不认为围绕你应该使用描述性符号名称的“约束”工作我会认为它是故意在脚下开枪。

【解决方案2】：

我不知道你的问题的答案，但我可以回答一个类似的问题：为什么我们在数据库中使用联结表来处理多对多关系？

首先，如果学生表跟踪学生在哪些课程上，并且课程跟踪哪些学生在其中，那么我们就有重复。这可能会导致问题。如果学生知道它在课程中，但课程不知道它有那个学生怎么办。每次您进行课程更改时，您都必须确保在两个表格中都进行更改。不可避免地不会每次都发生这种情况，并且数据会变得不一致。

其次，我们会将这些信息存储在哪里？列表不是数据库中字段的可能类型。那么我们是否在学生表中放置一个课程列？不，因为这只会让每个学生选修一门课程，学生与课程之间是多对一的关系。我们是否在课程表中放置一个学生列？不，因为这样我们每门课程都有一个学生。

有效的方法是创建一个新表，其中每行包含一名学生和一门课程。这告诉我们一个学生在课堂上没有复制任何数据。

【讨论】：

【解决方案3】：

“连接表”来自并不真正了解关系模型的 ER/ORM 演示文稿/方法/产品。

在关系模型中（以及在原始 ER 信息建模中）应用程序关系由关系/表表示。每个表都包含彼此处于该关系中的值元组，即相关性很高，即满足该关系，即参与该关系。

关系独立于任何特定情况表达为谓词，即填充（命名）空白语句。在特定情况下填写命名空白以从谓词中给出真实陈述的行进入表中。我们选择足够的谓词（因此是基表）来描述每种情况。多对一和多对多应用程序关系都获得表。

您没有看到很多多对多关系以及关于参与者的列而不是关于他们参与关系的列的原因是，这些表最好分成关于参与者的表和关于参与者的表。关系。例如，多对多表中关于参与者的列 1. 不能说任何关于不参与的实体和 2. 每次参与时都对实体说同样的话。专注于首先识别独立实体类型然后它们之间的关系的信息建模技术往往会导致设计很少出现此类问题。您在两个表中看不到多对多关系的原因是这是多余的并且容易受到表不一致的错误的影响。集合值列（序列/列表/数组）的问题在于，您无法使用通常的查询表示法和实现来一般地查询它们的部分，因为 DBMS 看不到组织成表的部分。

见this recent answer 或this one。

【讨论】：