多态关联——总是不好吗？

Question

我了解多态关联的概念以及如何使用 Martin Fowler 解释的表继承模式来避免它们。

假设您的数据库由包含许多实体类型 (1000+) 的大量表组成，并且假设您需要能够向存储在其中的任何实体添加评论或注释等内容数据库。

使用多态关联，您将创建一个包含可能具有 cmets 或注释的实体类型的表，以及一个包含类型 ID 和其表中实体的 ID 和注释的表。你显然没有得到引用完整性。

使用我遇到的基于继承的解决方案，在这种情况下的建议是创建一个表作为数据库中所有实体的根“类”，以便您可以在 ID 之间创建外键在这个表和 cmets 表中的一个 EntityID。

这意味着每个表中的每一行都需要该表中的一行，并且您需要在该表中插入一条记录以生成实体的 ID（我知道您可以使用唯一标识符，但它有其自身的缺陷）。对我来说，这感觉就像这张桌子周围会出现瓶颈。

另一种选择是在每个实体表和 cmets 表之间创建一个表。但是，如果您需要 cmets、notes、tags 等，您最终会大量增加数据库中的表数量。

有没有人尝试在现实世界中做这样的事情，您是否发现使用多态关联是一个更好的解决方案，尽管数据库中缺乏参照完整性？

Answer 1

这完全取决于您确定哪种解决方案更好的标准。

更简单的解决方案是创建单个多态关联表。这对于程序员来说一开始会更快。它符合有据可查的模式；特别是在当今流行的一些 MVC 类型框架中。然而，这实际上是更复杂的解决方案，因为现在有一个包含许多概念的表。此外，由于无法实现参照完整性，因此无法保证数据的正确性。

更简单的解决方案是为每个关系创建一个表，以便有一个包含单个概念的表。它允许使用参照完整性来保证数据的正确性和质量，并且软件维护人员可以更快地评估系统更改的影响。然而，这是一个更难的解决方案，因为它需要在最初创建更多的表。

现在由您来决定是否要选择更简单或更简单的解决方案。