我刚刚阅读了Chad Fowler关于
20 Rails Development No-Nos的博文.在单表继承中他评论道：

The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.

我正在编写一个博客应用程序,我正在考虑使用STI来评论可以在帖子上发布的内容以及访问者可以发布的联系消息,如果他们想与我联系的话.我的Message模型将继承我的Comment模型.它们都共享共同的属性,除了Message将有一个额外的主题字段.另一个共同点是两者都将被提交给Akismet进行垃圾邮件检查.

如果Chad建议它是正确的解决方案,而不仅仅是问自己不止一次,我想我也会从Stack Overflow专家那里得到一些意见！我提出的建议听起来是否适合STI？

最佳答案 我已多次使用过STI.考虑一个可能有Page,NewsItem,BlogItem等的CMS.

它们每个都可以从一个公共类继承,而该公共类继承自ActiveRecord.每个表的表格都是相同的(标题,正文,标签,published_at),但每个模型可能具有不同的关联,不同的状态或不同的工作流程,因此每个模型都有自己的类中的自定义代码.然而,他们都共享一个共同的表和父类.它还允许我使用父类进行跨类搜索,并使得生成的记录数组自动进行类型转换.

还有其他方法可以解决这个问题,也许不是最好的例子,但有时STI在对象行为可能不同但持久状态相同的情况下很方便.当然,你必须确保将来也是如此.

在您的情况下,评论和联系信息是不同的.听起来好像将它们放在同一张桌子上没有任何好处.也许将共享代码放在父类中,或者更好地放在/ lib中的模块中.