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

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

也就是说，我对此做了很多研究。我知道使用多态关联的缺点和优点。但我发现了一个似乎不错的解决方案：

http://blog.meta Mind.com/2010/11/25/stable-polymorphic-foreign-key-relations-in-rails-with-postgresql/ http://web.archive.org/web/20130926025456/http://blog.metaminded.com/2010/11/25/stable-polymorphic-foreign-key-relations-in-rails-with-postgresql/

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

你怎么看？应该完全避免这种解决方案吗？或者这是一个好的解决方案？

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

我在使用 PostgreSQL 时遇到的最大问题INHERITS实现是您不能设置对父表的外键引用。有一个lot您需要这样做的情况。请参阅我的答案末尾的示例。

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

我长期以来一直使用基本父表，使用外键强制执行不相交的子类型。此结构保证只能存在一个关联，并且该关联解析为父表中的正确子类型。 （在Bill Karwin 关于 SQL 反模式的幻灯片 http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back，这种方法从幻灯片 46 开始。）在简单的情况下，这不需要触发器，但我通常为每个子类型提供一个可更新的视图，并要求客户端代码使用这些视图。在 PostgreSQL 中，可更新视图需要编写触发器或规则。 （9.1之前的版本需要规则。）

在最一般的情况下，不相交的子类型不具有相同数量或类型的属性。这就是为什么我喜欢可更新的视图。

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

我认为您不必担心数据重复。首先，我非常确定父表和继承表之间的数据不会重复。看起来就是这样。其次，重复or其完整性完全由 dbms 控制的派生数据并不是一颗特别难以下咽的苦药丸。 （但不受控制的重复是。）

考虑一下删除是否应该级联。

• A 出版物示例 https://stackoverflow.com/questions/4969133/database-design-problem/4970646#4970646与 SQL 代码。
• A “当事人”的例子 https://stackoverflow.com/questions/4688972/different-user-types-objects-own-content-in-same-table-how/4690648#4690648与 SQL 代码。