问题标签 [single-table-inheritance]

我有这个想法，我一直在根据我在某处读到的另一个概念在脑海中思考。基本上，您有一个包含很少字段的“主”表，其他表通过外键继承该主表。以前做过这么多，所以没有消息。我想做的是让数据库中的几乎每个表都继承自该主表。这样，每个表中的每个对象、每个记录、每个条目都可以有一个完全唯一的主键（因为 PK 实际上存储在 Primary 表中），并且可以简单地通过 ID 而不是通过 table 来引用。

另一个好处是可以很容易地建立可以触及多个表的关系。例如：我有一个 Transaction 表，并且该表希望对任何事务（库存、帐户、联系人、订单等）都有一个 FK。事务可以只对主表有一个 FK，并通过它引用必要的数据。

我脑海中不断出现的问题是，主表是否会成为瓶颈。这件事将在某一时刻拥有数百万条记录。我知道通过良好的表格设计可以处理巨大的记录集，但限制是什么？

有没有人尝试过类似的事情，你的结果是什么？

我之前问过一个问题，关于如何在我正在构建的用于管理内容的简单应用程序中构造数据。答案是查看单表继承，我认为这将成为门票。

我已经阅读了很多示例，但似乎总是被遗漏的一件事是 :type 列实际上是如何填充的？我是否包含带有下拉菜单的表单字段，以便用户可以选择类型？

我相信我现在完全理解 STI 的工作原理（类型字段采用类名），但仍然缺少一些非常基本的东西（可能非常明显，但我错过了）。有人可以填我吗？

我有一个像这样的内容表：

不同的类型是“站点”、“博客”、“照片”。

Object#is_a?在 Rails 3 中以最奇怪的方式失败。我的单表继承设置如下（为简洁起见）：

在我的控制器中，我有这个：

调用该#create操作会生成以下日志结果：

请注意，该Video实例是一个ActiveRecord::Base，但它不是一个Resource。这不仅仅是一个学术问题。从操作调用的框架代码is_a?用于检查类型不匹配，当它认为Video不是Resource.

然而在 Rails 控制台中，is_a?(Resource)返回 true。

这里到底发生了什么？

我正在编写一个网站，该网站允许用户发布分类广告，其中包含他们销售的不同类型商品的详细字段。但是，我有一个关于最佳数据库模式的问题。

该网站具有许多类别（例如汽车、计算机、相机），并且每个类别的广告都有自己不同的领域。例如，汽车具有门数、品牌、型号和马力等属性，而计算机具有 CPU、RAM、主板型号等属性。

现在因为它们都是列表，所以我正在考虑一种多态方法，为每个不同的类别（计算机、汽车、相机）创建一个父 LISTINGS 表和一个不同的子表。每个子表都有一个listing_id，它将链接回列表表。因此，当获取列表时，它将从 LISTINGS 中获取一行，该行由关联子表中的链接行连接。

现在，这个模式是一个好的设计模式还是有更好的方法来做到这一点？

我考虑过单继承，但很快就打消了这个念头，因为表会变得太大太快，但随后又想到了另一个难题——如果用户对所有列表进行全局搜索，那么这意味着我将不得不查询每个孩子分开表。如果我有超过 100 个不同的类别会发生什么，会不会效率低下？

我还想到了另一种方法，其中有一个定义每个类别中的字段的主表（元表）和一个存储每个列表的字段值的字段表，但这会违反数据库规范化吗？

像 Kijiji 这样的网站是如何做到的？

我无法为使用 STI 的表加载固定装置。

当我打电话时FIXTURES=schools rake db:fixtures:load，我收到此错误：

• 其他夹具加载正常，即FIXTURES=committes rake db:fixtures:load
• 夹具是通过调用创建的rake db:fixtures:extract

这是我的学校迁移：

我有一些模型文件，即school.rb：

并且secondary_school.rb：

这是堆栈跟踪：

还有一些示例 YML：

我有一个正在构建的应用程序来学习 Rails。这是一个简单的页面管理器，使用 awesome_nested_set 来创建嵌套页面。我想使用 STI，但不确定如何使用。我看到的大多数 STI 示例都涉及主要的“宠物”模型和“狗”和“猫”的子模型；我很难把它变成现实世界的例子。这是我使用这些页面的方式。

3 种不同的页面“类型”：博客、照片、手机照片。真正描述这一点的唯一方法是向您展示我当前在 Coldfusion博客、照片、移动照片中构建的网站。

所有这些都使用相同的表和几乎相同的属性。照片部分使用照片属性并进行了一些小的更改，例如上传、调整大小等——但除此之外，不同“类型”之间的一切都是相同的。页面类型之间的主要区别在于页面的布局方式和访问方式。例如：

在索引上：
/photos - 显示所有页面的布局缩略图，带有“照片”类型
/blog - 布局显示所有页面，带有“博客”类型

在节目中：
/photos/1 - 显示带有上一个/下一个照片的大照片
/blog/2 - 显示带有上一个/下一个条目的博客条目

每种类型都需要单独的控制器吗？如果我不需要对页面的创建/更新方式进行任何更改，我是否需要单独的模型？我是否只是创建指向呈现我需要的布局的动作的路线？我想我看到了“STI”这个词，让它变得比它必须的更难。我只是很谨慎，因为我想学习“rails way”。我什至需要性病吗？

任何帮助将不胜感激，我只需要克服这个困难，有人帮助让它“点击”！:)

在使用 STI 时，我试图获取特定 :type 的所有页面。

我在 pages_controller.rb 中有一个主类

在此之下，我在 pages_controller.rb 中有另一个类

Blog 类不应该获取所有具有“博客”类型的页面吗？相反，无论类型如何，它都会获取所有页面。我也试过@pages = Page.where(:type => "Blog")我正在访问 URL http://localhost:3000/blog

这是我的路线

我必须为可以是教师、学生、局外人类型的人员实施单表继承。

注册新用户时，我需要对路线和表格进行哪些更改。我在人员表中有一个列（字符串）“类型”，它可以实现为表单中的下拉列表以注册新用户。我还需要在表单中做些什么，以便将用户注册为特定类型的人吗？我是否也需要对路线进行任何更改？

我已经为一个人类实现了单表继承

并且 create person 似乎根据在 form.select 中选择的内容创建了 Teacher、Student 或 Person，并添加了 type 属性。

但是，我似乎打破了路线

<%= link_to '编辑', edit_person_path(@deal) %> | <%= link_to '返回', people_path %>

他们似乎指向teacher_path、student_path 和outsider_path 而不是person_path。

路线需要做哪些改变？

我的 Rails 视图和控制器充斥着redirect_to、link_to和form_for方法调用。有时link_to和redirect_to在它们链接的路径中是显式的（例如link_to 'New Person', new_person_path），但很多时候路径是隐式的（例如link_to 'Show', person）。

我在模型中添加了一些单表继承（STI）（比如Employee < Person），所有这些方法都因子类的实例而中断（比如Employee）；当 rails 执行时link_to @person，它会出错undefined method employee_path' for #<#<Class:0x000001022bcd40>:0x0000010226d038>。Rails 正在寻找由对象的类名定义的路由，即employee。这些员工路线没有定义，也没有员工控制器，因此也没有定义操作。

之前有人问过这个问题：

1. 在StackOverflow，答案是在整个代码库中编辑 link_to 等的每个实例，并明确说明路径
2. 再次在StackOverflow上，有两个人建议使用routes.rb将子类资源映射到父类（map.resources :employees, :controller => 'people'）。同一个 SO 问题中的最佳答案建议使用类型转换代码库中的每个实例对象.becomes
3. StackOverflow上的另一个问题，最佳答案是 Do Repeat Yourself 阵营，并建议为每个子类创建重复的脚手架。
4. 在SO再次出现同样的问题，其中最佳答案似乎是错误的（Rails magic Just Works！）
5. 在网络的其他地方，我发现了这篇博文，F2Andy 建议在代码中各处的路径中进行编辑。
6. 在 Logical Reality Design的博客文章Single Table Inheritance and RESTful Routes中，建议将子类的资源映射到超类控制器，如上面的 SO 答案 2 中所示。
7. Alex Reisner 在 Rails 中有一篇文章Single Table Inheritance，其中他主张反对将子类的资源映射到父类routes.rb，因为这只能捕获来自link_toand的路由中断redirect_to，而不是来自form_for. 所以他建议改为向父类添加一个方法，让子类对他们的类撒谎。听起来不错，但他的方法给了我错误undefined local variable or method `child' for #。

所以看起来最优雅和最一致的答案（但它不是那么优雅，也不是那么一致），就是将资源添加到你的routes.rb. 除非这不适用于form_for. 我需要一些澄清！为了提炼上面的选择，我的选择是

1. 将子类的资源映射到超类的控制器中routes.rb（并希望我不需要在任何子类上调用 form_for）
2. 覆盖 rails 内部方法以使类相互欺骗
3. 编辑代码中隐式或显式调用对象操作路径的每个实例，更改路径或对对象进行类型转换。

有了所有这些相互矛盾的答案，我需要一个裁决。在我看来，没有好的答案。这是rails设计的失败吗？如果是这样，这是一个可以修复的错误吗？或者如果不是，那么我希望有人可以让我明白这一点，让我了解每个选项的优缺点（或解释为什么这不是一个选项），哪个是正确答案，以及为什么。或者有没有我在网上找不到的正确答案？