为什么 Rails 在多态关联和 STI 中使用基类名而不是子类名？答案

【问题标题】：Why does Rails use the base class name, and not the subclass name, with polymorphic associations and STI?为什么 Rails 在多态关联和 STI 中使用基类名而不是子类名？
【发布时间】：2020-01-22 20:36:29
【问题描述】：

假设我有单表继承，BuyerInvoice 继承自 Invoice。

如果我将这样的发票分配给多态关联，Rails 将存储例如record_type: "Invoice" 而不是 record_type: "BuyerInvoice"。它存储record.class.base_class.name。

他们这样做的原因有哪些？我正在实现一些模糊相似的东西，并想了解 Rails 可能做出这个决定的原因。

我能想到的最好的一点是，在不影响关联的情况下重命名子类变得更容易一些，尽管这样做会更容易重命名抽象超类......

【问题讨论】：

STI 的一半要点是避免多态关联。
@max 它可以避免一些多态关联，但不能避免其他关联（bookable.record_type/id，其中记录是例如发票或付款）。而且事实仍然是 Rails 以这种方式处理多态 STI，所以问题是:)

标签： ruby-on-rails

【解决方案1】：

STI 是模型的实现细节，它不应该泄漏到它的关系中。

除了重命名子类：

STI 可以通过自定义类解析来实现（类型列根本不是类名），甚至在一些奇怪的情况下，类会根据属性等动态变化。
STI 可以在已有关系后添加到模型中
完全可以去除性病

【讨论】：

谢谢！好点。关于“STI 可以被移除”这一点——我想这取决于你如何移除它。如果我稍后将“BuyerInvoice”分解到它的表中，如果它现在存储“Invoice”基类，我需要更改现有的多态关联。
@HenrikN 是的，当然这取决于具体情况，我的意思是删除以支持单个通用类，同时保持数据库架构和数据完整。如果您将invoices 表拆分为两个 - 您已经必须修改结构和数据，因此也应该修改关联是合乎逻辑的
我想到的另一个原因——不确定是否有一个真正的应用程序，但是——如果 Rails 需要找到一堆关联的记录并且希望用最少的查询来做到这一点，那么存储基类使其可以进行单个查询 (Invoice.where(id: a_bunch_of_associated_ids))，而不是每个子类一个。