多对多的关联表——在这些表中增加列是惯例吗?

我一点也不觉得有问题。如果信息与关联本身有关,那么它似乎是存储关联的绝对正确位置。

如果您要创建一个新表来存储这个表,它将只与Association表相关,无论如何都是一对一的。这基本上只是扩展关联表。

我以前做过这个,不认为有什么问题。如果数据与关系有关,例如在您的情况下,它是关联发生的日期,并且不专门属于一个表或另一个表,那么关联表就是放置它的地方。

如果数据实际上与关系有关,而不是与单个实体有关……那么是的,将其放在透视表中。

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

在这个设计中,您将关联本身视为一个实体。如果其他两个实体之间的关系这个现实世界实体有自己的属性,那么表示该关系的表也应该表示该关系的属性。

如果您创建了一个单独的表,那么您将使用该表建模什么真实的实体?与两个实体之间的关系相关但不是直接相关的辅助信息?这很难概念化,似乎没有太多的设计意义,而且几乎可以肯定的是性能会更差。

“然而,有件事告诉我,这是数据库纯粹主义者所不赞成的。”

我无法想象任何一个熟悉数据库设计的人会对你的设计不满,如果这个设计真的是你所面对的现实的精确模型。

在 this recent answer 我提倡使用链接表而不是简单的FK关系。其中一个好处是当关系开始有越来越多的数据与之关联,从而使其成为一个实体时。具体来说,即使在简单的多对一层次结构中,使用多对多链接表设计仍然很有意义。显然,您已经有了对链接表的需求——现在很明显,该关系中还附加了其他属性。

当然,事实证明这些属性是放置这些属性的正确位置;您可能会遇到一些困难,将它们放在任何一个表中,要么使用规范化,要么只是简单地使用不正确的语义。这也为索引提供了很好的选择,因为您可以将有效日期或关系状态的索引添加到此相对狭窄的表中,而无需决定在其他实体表中可能需要添加哪些索引。

我不认为任何有经验的数据库设计师会反对,如果你展示了设计,以及它的设计特点和优势是如何在实践中使用的。对我来说,它不需要广泛的设计理由。