对我的一个关于数据库设计的问题的回答提出了一种叫做单表继承的东西。我已经对此进行了一些搜索，但似乎无法找到有关它的清晰信息。
基本上我似乎从中了解到的是，您有一个包含所有字段的大表以及一个类型字段 - 然后您的 ORM 层使用类型字段为您提供不同的对象视图。那是对的吗？
更重要的是，单表继承是一种“认可”的数据库设计技术吗？我的意思是使用它是否“明智”？使用它也安全吗，还是会引起问题？
另一个问题是这在 Rails 中的效果如何？我从 Rails 中找到了一些对它的引用——但它是否会因为以非常规的方式做事而导致问题？
非常感谢任何帮助。
这是个好主意吗 ？这取决于。它打破了规范化，因为表没有单一用途。当您第 n 次扩展基类时会发生什么？您将不得不向表中添加列。大多数现代数据库对此没有问题，因为您可以修改表，但是重构和删除类呢。现在您有了没有目的的列。
一条经验法则——如果大部分设计都已经完成，那么使用起来可能是安全的。如果设计经常更改 - 您还有其他问题，您需要锁定您的用例/用户需求。（是的，不是真正的 XP 友好）
我不知道 Rails 效果。
STI 是一种处理面向对象和面向数据库的思维之间不匹配的方法。它允许数据库内信息的合理表示和对象模型内的不同表示。
例如，我有一个应用程序，其中我的每个产品都包含一个或多个费用，每个费用的计算方式略有不同。在我的对象模型中，我希望有一个 Fee 类的子类，每个子类都知道如何计算自己。不过，我真的不想为每种费用类型创建一个表：所以我将费用创建为基类，并将费用创建为表，其中包含所有子类型所需的所有字段的联合，以及一个“类型”其值对应于相关子类的名称的列。此后 ActiveRecord 处理管道。
简而言之，单表继承 (STI) 是一种允许将 OOP 继承关系映射到数据库的设计模式。如果您从 ActiveRecord 模型对象定义任何子类，那么您应该考虑 STI。
STI（最初？）记录在 Martin Fowler 的“企业应用程序架构模式”一书中，并且也在 DHH 的规范 Rails 书“使用 Rails 的敏捷 Web 开发”（我认为是第 18.4 节）中进行了描述。我推荐你参考这些书是因为他们提供了比我希望在这个领域做的更好的解释。
我强烈不同意 www.matthewpaulmoore.com（由 robintw 在此线程中链接）所表达的观点，即 STI 本质上是一件坏事。这似乎是一种有点幼稚的观点，它低估了 OOP 继承的使用。我使用 STI 在 Rails 中创建了一些优雅的解决方案，但我想你可以滥用任何设计模式。
权威参考。它允许单个表存储具有公共基类的多个对象。
Ruby on Rails 使用一个名为Active Record的库。这是一个支持 STI 的通用 Ruby 框架。
我只能从（新的）ADO 实体框架的角度讲，它包括每个类型的表 (TPT) 功能。
这是一个很好的系列博客文章，介绍了核心概念（使用实体框架），这里也有一篇关于它的 MSDN 论文。
使用 nHibernate 进行 TPT 时似乎也有一些指导，它位于此处。
有这个链接解释了 SQL Server 中的 table-per-type 继承。这似乎对概念进行了很好的总结和介绍。
我不确定它会对 Rails 产生什么影响。
我刚刚看到http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti这表明这是一个坏主意。
通常我觉得它很有用，但我遇到了一些错误
该链接中的示例可能会为您提供如何使用它的有用图片。