我们在数据库中遇到了以下情况。我们有表“A”和表“B”，它们具有 M2M 关系。关联表名为“AB”，包含表“A”的 FK 列和表“B”的 FK 列。现在我们已经确定需要存储有关此关联的其他数据。例如，关联发生的日期，以及关联的人等。我们决定将这些附加列放在“AB”关联表中。然而，有些事情告诉我，数据库纯粹主义者对此并不满意。另一方面，对我们来说创建一个额外的表来存储这些关联数据是没有意义的。
对此的普遍看法是什么？
【问题讨论】：
标签： sql-server database database-design
我认为这没有任何问题。如果信息与关联本身有关，那么存储它似乎是绝对正确的位置。
如果您要创建一个新表来存储它，它只会与关联表一一对应。这基本上只是扩展关联表。
【讨论】：
我以前做过，不认为有什么问题。如果数据与关系有关，例如在您的情况下，它是关联发生的日期，并且不专门属于一个表或另一个表，则关联表就是放置它的地方。
【讨论】：
如果数据实际上与关系有关，而不是单个实体之一...那么是的，将其放入数据透视表中。
【讨论】：
将有关关联的数据存储在关联表本身中是最有意义的。我从来没有听说过有人不赞成这种方法...实际上它会比将这些信息存储在单独的表中更快，因为它会为您节省一个连接来检索它。
【讨论】：
在此设计中，您将关联本身视为一个实体。如果现实世界的实体，即其他两个实体之间的关系，有自己的属性，那么表示该关系的表也应该表示该关系的属性。
如果您创建了一个单独的表格，您会使用该表格对哪个真实世界的实体进行建模？与两个实体之间的关系相关但不直接属于其中的辅助信息？这很难概念化，似乎没有太大的设计意义，而且几乎肯定会表现得更差。
【讨论】：
“但是，有件事告诉我，数据库纯粹主义者不赞成这种做法。”
我无法想象有任何人在数据库设计方面知识渊博并且会对您的设计皱眉头，如果该设计真的是您正在处理的现实的准确模型。
【讨论】：
在this recent answer 中，我提倡使用链接表而不是简单的FK 关系。好处之一是当关系开始有越来越多的数据与之关联时，它就会成为一个实体。特别是即使在简单的多对一层次结构中有效日期和更改，使用多对多链接表设计仍然很有意义。您显然已经需要链接表 - 现在很明显存在附加到该关系的其他属性。
当然，事实证明这些是放置这些属性的正确位置；您可能会在将它们放在任一表中时遇到一些困难，无论是使用规范化还是仅仅使用不正确的语义。这也为索引提供了很好的选择，因为您可以将生效日期或关系状态的索引添加到这个相对狭窄的表中，而无需决定它可能需要添加到其他实体表中的哪些索引
如果您展示设计以及在实践中如何使用它的设计特性和优势，我认为任何有经验的数据库设计师都不会反对。对我来说，它不需要大量的设计理由。
【讨论】：