因此出于多种原因,多态关联被认为是糟糕的数据库设计,例如您不能在多态 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。
最佳答案
另一种选择是完全规范化您的数据库结构,并使用 View 将数据转换为更适合查询的形式。我不确定这对不同的 ORM 有多好,所以你的里程可能会有所不同。总的来说,我发现最好将数据模型建立在数据真正结构化的基础上,因为这往往有助于简化维护。数据正确建模后,您可以创建 View 和存储过程以方便地访问和操作数据。
关于sql - 用什么代替多态关联?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13272776/