sql - 用什么代替多态关联？

Question

因此出于多种原因，多态关联被认为是糟糕的数据库设计，例如您不能在多态 id 列上有外键，因此引用完整性消失了。

并且，STI 也被认为是不良的除非子类型仅在行为上有所不同。

所以我的问题是对于 Rails/ActiveRecord 在以下情况下什么是较小的邪恶:

我需要允许我的用户创建一个包含多种类型实体的手工排序集合。

使用多态关联，模式看起来像这样:

-- collections
id, name, ...

-- exhibits
id, collection_id, exhibitable_type, exhibitable_id, position

-- photographs
id, ...

-- films
id, ...

-- paintings
id, ...

-- songs
id, ...

-- sculptures
id, ...

我可以使用 STI 并拥有类似这样的东西:

-- collections
id, name, ...

-- exhibits
id, collection_id, artwork_id, position

-- artworks
id, type, <photograph columns>, <film columns>, <painting columns>, etc.

但是，因为我的艺术作品在数据上有所不同(而不仅仅是行为)，所以我现在在艺术作品表中到处都是空值。我还为我的对象引入了一个以前不存在的继承层次结构，我通常对此持谨慎态度，尤其是当它的唯一目的是为数据库设计服务时。

STI 看起来确实至少更易于查询和编码。

那么哪个是较小的邪恶？

那么，另一种选择是多表继承:

-- collections
id, name, ...

-- exhibits
id, collection_id, artwork_id, position

-- artworks
id

-- photographs
artwork_id, <photograph columns>

-- films
artwork_id, <film columns>

这将消除 STI 的 NULL 问题，同时减小表的大小。我们仍然有我认为不是绝对必要的对象层次结构。但是我眼中最大的问题是:Rails 不支持。 CITIER gem 看起来非常好，它有最近的提交，但它并没有被广泛使用，所以我对在我的应用程序的基础上使用它持谨慎态度。我想我也可以考虑使用 Sequel 或其他支持 CTI 的 ORM。

说实话我觉得我最喜欢多表继承的方案

如果我不需要位置列，我会简单地使用单独的连接表，如 collections_photographs、collections_paintings、collections_films 等，但是我确实需要手动订购。

所以，看起来选项是:

• PA:引用完整性丢失(如果始终使用 ActiveRecord 进行数据库访问在实践中是否重要？)
• STI:包含大量空值的大表
• CTI/MTI:依赖于未被广泛使用的 gem

哪个是较小的邪恶，还有其他选择吗？我正在使用 Postgres。

Answer 1

另一种选择是完全规范化您的数据库结构，并使用 View 将数据转换为更适合查询的形式。我不确定这对不同的 ORM 有多好，所以你的里程可能会有所不同。总的来说，我发现最好将数据模型建立在数据真正结构化的基础上，因为这往往有助于简化维护。数据正确建模后，您可以创建 View 和存储过程以方便地访问和操作数据。