多对多关联表 - 习惯上在这些表中添加其他列吗？

Question

我们在数据库中遇到以下情况。我们有表'A'和表'B'，它们具有M2M关系。关联表名为'AB'，包含表'A'的FK列和表'B'的FK列。现在我们已经确定需要存储有关此关联的其他数据。例如，关联发生的日期，以及谁建立关联等。我们决定将这些附加列放在“AB”关联表中。然而，有些东西告诉我这是数据库纯粹主义者所不满意的。另一方面，我们创建一个额外的表来存储这些相关数据是没有意义的。

对此有何普遍看法？

Answer 1

我完全没有看错。如果信息与关联本身有关，那么它似乎是存储它的绝对正确的地方。

如果要创建一个新表来存储它，它只会与关联表一对一关联。这基本上只是扩展了关联表。

Answer 2

我之前已经这样做过，并且认为它没有任何问题。如果数据与关系有关，例如在关联发生的日期，并且不属于一个表或另一个表，则关联表是放置它的位置。

Answer 3

如果数据实际上与关系有关，而不是单个实体之一......那么是，将它放在数据透视表中。

Answer 4

最有意义的是在关联表本身中存储关于关联的数据。我从来没有听说过有人对这种方法不满意......它实际上会加速将这些信息存储在一个单独的表中，因为它会为你保存一个连接来检索它。

Answer 5

在此设计中，您将关联本身视为一个实体。如果该真实世界实体（其他两个实体之间的关系）具有自己的属性，则表示该关系的表也应表示该关系的属性。

如果您创建了一个单独的表，那么您将使用该表建模哪个真实世界实体？与两个实体之间关系的一部分有关但不直接相关的辅助信息？这很难概念化，似乎没有太多的设计意义，而且几乎肯定会表现得更差。

Answer 6

“然而，有些东西告诉我这是数据库纯粹主义者所不满的。”

我无法想象任何对数据库设计有所了解并且对你的设计不满意的人，如果那个设计确实是你正在处理的现实的准确模型。

Answer 7

在this recent answer中，我提倡链接表而不是简单的FK关系。其中一个好处是，当关系开始拥有越来越多的数据时，它就会成为一个实体。特别是即使在简单的多对一层次结构中，有效的日期和更改，使用多对多链接表设计仍然很有意义。您显然已经需要链接表 - 现在很明显，该关系附加了其他属性。

当然，事实证明这些是放置这些属性的正确位置;你可能会遇到一些困难，把它们放在任何一个表中，无论是标准化还是普通的错误语义。这也为索引提供了很好的选择，因为您可以将生效日期或关系状态的索引添加到此相对较窄的表中，而无需决定在其他实体表中可能需要将哪些索引添加到其他实体表中

如果您展示设计以及如何在实践中使用它的设计特性和优势，我认为任何有经验的数据库设计师都不会反对。对我而言，它不需要广泛的设计理由。