8

因此，出于多种原因，多态关联被认为是糟糕的数据库设计，例如，多态 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.

但是，因为我的作品在数据上有所不同（而不仅仅是行为），所以现在我的作品表中都有 NULL。我还为我的对象引入了以前不存在的继承层次结构，我通常对此保持警惕，特别是当它的唯一目的是为数据库设计服务时。

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。

4

2 回答 2

2

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

于 2012-11-08T13:41:10.700 回答
0

如果在 Postgres 中使用分区表，则可以同时实现多态性和外键，因为表示不同分区的表可以分别表示不同的子类型，并且每个表都可以具有不同的约束集。

于 2012-11-08T18:21:06.743 回答