postgresql - 多态关联外键约束。这是一个好的解决方案吗？

Question

我们在我们的应用程序中使用多态关联。我们遇到了经典问题:我们遇到了无效的外键引用，我们无法创建外键约束，因为它是一个多态关联。

也就是说，我对此进行了大量研究。我知道使用多态关联的缺点和优点。但我发现了一个看起来不错的解决方案:

http://blog.metaminded.com/2010/11/25/stable-polymorphic-foreign-key-relations-in-rails-with-postgresql/

这很好，因为您可以两全其美。我担心的是数据重复。我对 postgresql 的了解不够深入，无法完全理解此解决方案的成本。

你有什么想法？应该完全避免这种解决方案吗？或者这是一个好的解决方案？

在我看来，唯一的选择是为每个关联类型创建一个外键。但是随后您会验证仅存在一个关联。这是一种“选择你的毒药”的情况。多态关联清楚地描述了意图，也使这种情况变得不可能。在我看来，这是最重要的。数据库外键约束是幕后功能，改变“意图”以处理数据库限制对我来说是错误的。这就是为什么我想使用上述解决方案，假设没有明显的“避免”。

Answer 1

我在 PostgreSQL 的 INHERITS 实现中遇到的最大问题是您无法设置对父表的外键引用。在很多情况下您需要这样做。请参阅我的回答末尾的示例。

在 Rails 之外创建表、 View 或触发器的决定是至关重要的。一旦你决定这样做，那么我认为你不妨使用你能找到的最好的结构。

我长期以来一直使用基本父表，使用外键强制执行不相交的子类型。此结构保证只能存在一个关联，并且该关联解析为父表中的正确子类型。 (在 Bill Karwin's slideshow on SQL antipatterns 中，此方法从幻灯片 46 开始。)这在简单情况下不需要触发器，但我通常为每个子类型提供一个可更新 View ，并要求客户端代码使用这些 View 。在 PostgreSQL 中，可更新 View 需要编写触发器或规则。 (9.1之前的版本需要规则。)

在大多数情况下，不相交的子类型不具有相同数量或种类的属性。这就是我喜欢可更新 View 的原因。

表继承不可移植，但这种结构可以。您甚至可以在 MySQL 中实现它。在 MySQL 中，您必须将 CHECK 约束替换为对单行表的外键引用。 (MySQL 解析并忽略 CHECK 约束。)

我认为您不必担心数据重复。首先，我很确定父表和继承表之间的数据不会重复。它只是看起来那样。其次，复制 或 其完整性完全由 dbms 控制的派生数据并不是特别难以下咽的苦药。 (但不受控制的复制是。)

考虑是否应该级联删除。

• A publications example使用 SQL 代码。
• A "parties" example使用 SQL 代码。