单表继承
对我关于数据库设计的问题的回答提出了一种称为单表继承的东西。 我对此进行了一些搜索，但似乎找不到太多明确的信息。
基本上我从中了解到的是，你有一个大表，其中包含所有字段以及一个类型字段 - 然后你的 ORM 层使用类型字段为你提供不同的对象视图。 那是对的吗？
更重要的是，单表继承是一种“认可的”数据库设计技术吗？ 我的意思是使用它“明智”吗？ 使用它是否也安全，或者会引起问题吗？
另一个问题是这在 Rails 中效果如何？ 我从 Rails 中找到了一些对它的引用 - 但是以非常规方式做事会导致问题吗？
非常感谢任何帮助。
An answer to a question of mine on DB design suggested something called single table inheritance. I've done a bit of searching on that, but I can't seem to find that much clear information on it.
Basically what I seem to understand from it is that you have a big table with all the fields in it and also a type field - and then your ORM layer uses the type field to give you different object views. Is that correct?
More importantly, is single table inheritance an 'approved' database design technique? By that I mean is it 'sensible' to use it? Is it also safe to use it, or does it cause problems?
The other issue is how well this works in rails? I've found a few references to it from rails - but does it cause problems by doing things the non-conventional way?
Any help much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这是不是一个好主意 ？ 这取决于。 它破坏了规范化，因为表没有单一用途。 当你第 n 次扩展基类时会发生什么？ 您必须向表中添加列。 大多数现代数据库都没有这个问题，因为您可以修改表，但是重构和删除类又如何呢？ 现在你的专栏没有目的。
经验法则 - 如果大部分设计已经完成，那么使用起来可能是安全的。 如果设计经常更改 - 您还有其他问题，并且需要锁定您的用例/用户需求。 （是的，对 XP 不太友好）
我不知道 Rails 效果。
Is it a good idea ? It depends. It breaks Normalization in that a table does not have a single purpose. What happens when you extend the base class for the nth time ? You will have to add columns to the table. Most modern DBs don't have a problem with that as you can modify the table but what about refactoring and removing a class. Now you have columns that don't have a purpose.
A rule of thumb - if most of design has been worked out, it's probably safe to use. If the design is changing frequently - you have other issues and you need to lock down your use cases/user requirements. (yes, not really XP friendly)
I don't know about the Rails effects.
STI 是一种处理面向对象和面向数据库思维之间不匹配的方法。 它允许在数据库中合理地表示信息，并在对象模型中使用不同的表示。
例如，我有一个应用程序，其中我的每种产品都包含一项或多项费用，每种费用的计算方式略有不同。 在我的对象模型中，我希望有 Fee 类的子类，每个子类都知道如何计算自身。 不过，我真的不想为每种费用类型创建一个表：因此我创建 Fee 作为基类，并创建 Fees 作为表，其中包含所有子类型所需的所有字段的并集，以及“类型”其值对应于相关子类的名称的列。 ActiveRecord 处理此后的管道。
STI is a way of dealing with a mismatch between object- and database-oriented thinking. It allows a reasonable representation of the information within the database and a different representation within the object model.
For example, I have an application where each of my products contains one or more fees, each calculated slightly differently. Within my object model I want to have subclasses of a Fee class, each of which knows how to calculate itself. I don't really want to have a table per fee type though: so I create Fee as the base class and fees as the table, which contains the union of all the fields needed across all the sub-types, plus a "type" column whose value corresponds to the name of the relevant sub-class. ActiveRecord handles the plumbing thereafter.
简而言之，单表继承 (STI) 是一种允许将 OOP 继承关系映射到数据库的设计模式。 如果您从 ActiveRecord 模型对象定义任何子类，那么您应该考虑 STI。
STI（最初？）记录在 Martin Fowler 的“企业应用程序架构模式”一书中，并且在 DHH 的规范 Rails 书籍“使用 Rails 进行敏捷 Web 开发”（我认为第 18.4 节）中也有描述。我推荐您阅读这些书是因为他们提供的解释比我在这个领域所希望的要好得多。
我强烈不同意 www.matthewpaulmoore.com（由本帖子中的 robintw 链接）表达的观点，即 STI 本质上是一件坏事。 这似乎是一个有点幼稚的观点，它低估了 OOP 继承的使用。 我已经使用 STI 在 Rails 中创建了一些优雅的解决方案，但我想您可以滥用任何设计模式。
In short, Single Table Inheritance (STI) is a design pattern that allows a mapping of OOP inheritance relationships to the database. If you define any subclasses from your ActiveRecord model objects, then you should consider STI.
STI is (originally?) documented in Martin Fowler's 'Patterns of Enterprise Application Architecture' book, and is also described in DHH's canonical Rails book 'Agile Web Development with Rails' (section 18.4, I think.) I refer you to these books because they provide a much better explanation than I could hope to do in this space.
I strongly disagree with the sentiment expressed at www.matthewpaulmoore.com (linked by robintw in this thread), that STI is inherently a bad thing. This seems to be a somewhat naive view that discounts the usage of OOP inheritance. I have used STI to create some elegant solutions in Rails, but you can abuse any design pattern, I suppose.
最终参考。 它允许单个表存储具有公共基类的多个对象。
Ruby on Rails 使用名为 Active Record 的库。 这是一个支持STI的通用Ruby框架。
Definitive reference. It allows a single table to store multiple objects that have a common base class.
Ruby on Rails uses a library called Active Record. This is a common Ruby framework that supports STI.
我只能从（新）ADO 实体框架的角度进行讨论，其中包括每个类型表 (TPT) 功能。
这里是一系列很好的博客文章介绍了核心概念（使用实体框架），并且还有一篇 MSDN 论文 这里。
使用 nHibernate 进行 TPT 时似乎还有一些指导，它位于 here 。
这个链接解释了 SQL Server 中的每类型表继承。 这似乎对这个概念有一个很好的总结和介绍。
我不确定它会对 Rails 产生什么影响。
I can only speak from the (new) ADO Entity Framework perspective, which includes table-per-type (TPT) functionality.
Here is a good series of blog posts introducing the core concepts (using the Entity Framework) and there is an MSDN paper on it also here.
There also seems to be some guidance when using nHibernate for TPT, it's located here.
There's this link which explains table-per-type inheritance in SQL Server. This seems to have a pretty good summary and introduction to the concept.
I'm not sure what impact it would have on Rails.
我刚刚看到 http://www .matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti 这表明这是一个坏主意。
I've just seen http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti which suggests its a bad idea.
一般来说，我发现它很有用，但是我遇到了一些错误
该链接中的示例可能会提供有关如何使用它的有用图片。
Generally I find it useful, but I've encountered some bugs
The example in that link may provide a useful picture of how you might use it.