我刚刚阅读了Chad Fowler关于20 Rails Development No-Nos的博客文章。在单表继承他评论：
存储一个名为“type”的列，它保存了一个类名，这是一个非常好的指标，表明有些东西正在发生。它很可疑，但并不总是坏的。不过，我认为，无论何时使用它，如果它是正确的解决方案，你应该多次问自己。当你有很多STI和多态关联时，数据库也不会做他们最擅长的事情。
我正在编写一个博客应用程序，我正在考虑使用STI来发布可以在帖子上发表的评论以及访问者可以发布的联系消息，如果他们想与我联系的话。我的Message模型将继承自我的Comment模型。他们都有共同的属性，但Message将有一个额外的subject字段。另一个共同点是两者都将被提交给Akismet进行垃圾邮件检查。
而不是像Chad建议的那样，不仅仅问自己是否是正确的解决方案，我想我也会从Stack Overflow专家那里得到一些意见！我提出的建议听起来是否适合STI？
答案 0 :(得分：2)
我多次使用过STI。考虑一个可能包含Page，NewsItem，BlogItem等的CMS。
他们每个人都可以从一个公共类继承，而这个公共类继承自ActiveRecord。每个表的表格都是相同的（标题，正文，标签，published_at），但每个模型可能具有不同的关联，不同的状态或不同的工作流程，因此每个模型都有自己的类中的自定义代码。然而，他们都共享一个共同的表和父类。它还允许我使用父类进行跨类搜索，并使得生成的记录数组自动进行类型转换。
还有其他方法可以解决这个问题，也许不是最好的例子，但有时STI在对象行为可能不同但持久状态相同的情况下很方便。当然，你必须确保将来也是如此。
在您的情况下，评论和联系信息是不同的。听起来好像将它们放在同一张桌子上没有任何好处。也许将共享代码放在父类中，或者更好地放在/ lib中的模块中。