也许STI不是我想要的，并且我愿意接受所有建议，但是出于这个问题的考虑，让我们假设以下现实情况:
您希望您的应用包含不同邮件供应商的API数据。使用STI，您具有以下模型
class MailSetting < ActiveRecord::Base
belongs_to :user
end
class MailChimp < MailSetting
end
class AWeber < MailSetting
end
class PostageApp < MailSetting
end
现在让我们进行一些控制台操作:
user = User.first
setting = user.create_mail_setting(:type => "MailChimp")
好的，现在您要添加API密钥设置。 MailChimp仅使用api_key。 Aweber可能会使用api_key和签名，而Postageapp使用api_key和 token 系统。
您是否将每个子类扩展为包括数据库中所需的任何列？
您是否将STI全部废弃，只是将常规类称为
MailChimp，它继承自AR？我对STI的理由是，我知道我所有的用户都将拥有一个MailSetting，这种类型可能会随着时间的推移而扩展。但是，我发现以这种方式扩展这些子类非常麻烦，因为您无法在不知道
user.mail_setting.connect来自何子类的情况下进行诸如ojit_code之类的事情，然后，我需要如何连接这些家伙？有什么想法吗？
最佳答案
您应该使用多态类而不是STI
UPD
一些链接:
UPD 2
想象一下，我们需要Post模型。我们有从Post继承的Article和Topic。
rails g model Post title:string body:text content_type:string content_id:integer
因此，
title和body是Topic和Article的通用字段。现在让我们使用Topic中的user_id字段和Article中的link创建其他模型rails g model Topic user_id:integer
rails g model Article link:string
现在我们将编辑模型:
class Post < ActiveRecord::Base
belongs_to :content, :polymorphic => true, :dependent => :destroy
end
class Topic < ActiveRecord::Base
has_one :post, :as => :content, :dependent => :destroy
end
class Article < ActiveRecord::Base
has_one :post, :as => :content, :dependent => :destroy
end
它可能非常复杂，但是以这种方式挖掘:)
关于ruby-on-rails - STI和扩展子类以在数据库中包括 'extra'列？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4937893/