需要关联表的多对多关系答案

【问题标题】：Many-to-Many relationships needing an associate table需要关联表的多对多关系
【发布时间】：2020-05-14 17:57:03
【问题描述】：

在许多数据库设计教程/文章中，他们总是提出这样一个事实，即如果两个表共享多对多关系，则应创建第三个表作为关联表来链接两者。

然而，他们从来没有提供为什么我们应该这样做的原因。我很想知道为什么以及如果您将这两个表格保留为可能发生的问题示例它没有关联表。

【问题讨论】：

因为表格代表关系（船）/关联。 FK 有时被称为“关系”，但它们不是，也不需要记录或查询。它们是关联约束的一部分——关于关系（船）/关联和表的陈述——用于保持多个表的一致性。

【解决方案1】：

在关系数据库中，所有关系都只以一种方式表示：作为关系（关系对应于 SQL 中的表）。具有两个属性的关系，例如 R{A,B}，表示 A 和 B 之间的二元关系。这种关系可以是一对多或多对多。

如果由 R{A,B} 表示的关系是多对多的，这意味着 A 或 B 都不是候选键（因为如果任何一个都是唯一的，那么显然该属性的每个值只允许一个元组）。这意味着第三范式的原则要求任何依赖于 A 或 B 的属性进入其他表。原因是非关键依赖（依赖于 A 或 B 的属性）是一种冗余形式，可能导致异常和不正确的结果。

因此，“多对多关系”的表示方式与其他关系并没有任何不同。只是规范化通常会导致具有复合键且没有其他非键属性的表的常见模式。有些人喜欢将这种模式称为关联表 - 尽管我个人认为该术语没有多大帮助。

【讨论】：

【解决方案2】：

如果你不创建第三个表，根本就没有地方存储关系。

对于一对一或一对多关系，您可以将关系存储在其中一个表中。对于多对多关系，您必须单独存储关系。（好吧，理论上您可以将其存储为两个表中的逗号分隔的身份列表，但使用和维护这将是一场噩梦。）

【讨论】：

【解决方案3】：

您无法使用关系数据库以任何其他方式建立多对多关系。即，如果您有一个名为“person”的表，则不能创建“friends”列并期望在其中放置许多朋友的用户ID。您必须创建一个单独的表来保存关系本身。

【讨论】：

不幸的是，您将“关系”和“关系”这两个术语混为一谈，这意味着两个截然不同的事物。当然，你不是唯一一个，而且我注意到混淆两者的趋势越来越普遍 - 但对于试图了解关系模型的人来说，这一定是非常混乱的。
对不起。我与语言的关系是“一对多”，我是一个人，语言有很多种。（而且英文的不是我的第一个）

【解决方案4】：

让我们通过一个例子来理解它。如果您有两张桌子，一张用于苹果，另一张用于人，并且它们具有多对多关系；意思是一个人可以吃多个苹果，一个苹果可以分享给多人吃。

因此，如果我们在 person 表中为 apple 表添加一个外键，那么这就给出了一个苹果可以被多个人吃掉的关系，但我们没有指定相反的关系。看这张表

类似地，如果我们在 apple 表中的 person 表中添加一个外键，那么这给出了一个人可以吃多个苹果但另一个人不能吃的关系。参见这个表

所以这里是关联表。关联表用于两个对象之间的多对多关系。它们由至少 2 个外键组成，每个外键引用两个对象之一，并且关联表中的主键至少由 2 个外键组成。看这张表

参考： https://openclassrooms.com/en/courses/2071486-retrieve-data-using-sql/5758019-create-an-association-table

【讨论】：

【解决方案5】：

维基百科也描述了它。看看吧：http://en.wikipedia.org/wiki/Many-to-many_(data_model)

如果您仍然不相信多对多确实需要第三个表，只需尝试仅使用两个规范化表的 Authors/Books 示例（如维基百科文章中所述）。

【讨论】：

【解决方案6】：

如果 DB-Server 可以为您创建第三张表，那将不灵活。如果会有这样的解决方案，你不会有太大的影响

改变关系行为
在 assoc 中存储其他关联信息。表
性能增强
存储增强

【讨论】：