问题标签 [sti]

我最近刚刚继承了一个 Rails 应用程序，并且正在讨论向前推进的架构决策。这里有一些背景......感谢您的反馈。

目前有 16 种不同的广告类型，它们都具有一组相同的属性，一些具有一个或两个附加属性，还有一些具有三个或四个属性。

目前，每种广告类型都有一个单独的模型和带有相应列的表格，以及一个单独的控制器和 CMS 中的视图，也用于基本的 CRUD。CMS 利用了inherited_resources，从而限制了一些重复。

我写出了属性集——大约有 20 个，涵盖了所有广告类型。某些广告类型具有关联 - 几个 has_many 关联，其中外键存储在关联表中，还有一些属于_to。

广告没有实际行为。特定的广告类型只是简单地显示在各个页面上，所以只要我能确定是否有特定类型的广告，我们就可以了。

我正在讨论转向单个模型、表和控制器，但希望从 stackoverflow 社区获得尽可能多的输入，以了解这是否 1）非常适合问题 2）任何性能问题 3）任何潜力我没有想到的编程瓶颈。到目前为止，这是我的想法......

假设路线 /:location/:ad_type/new（例如 /homepage/ad_type_1/new）：

ad_controller 将创建 @ad 并将 ad_type 设置为 params[:location] + params[:ad_type] 并渲染新视图，该视图将包含一系列条件，用于显示给定 ad_type 的适当部分。提交将触发创建操作，使用为广告类型定义的预期属性创建广告，在这种情况下，其中之一是 ad_type = homepage_ad_type_1。

我没有过多考虑检索数据，但假设 ad_type 列设置正确，我应该能够创建一个基于 ad_type 列提取记录的“of_type”范围。不确定我是否在那里遗漏了什么。

验证将根据 ad_type 值而有所不同。

我不完全确定在任何给定时间会存在多少广告，但我觉得这可以在以后解决。通过将一些陈旧的行移到 ad_archives 表或类似的表中。

感谢您的想法。谢谢。

我正在开发一个项目，我有一个实体，它可能有两种资产：基本上是图片和视频。

由于我希望所有资产都在同一张表上，并且为Pictures或Videos提供一个上传表单，因此我使用的是 Single Table Inheritance，其中Picture和Video都从Asset类下降。此外，我将运行不同的验证/回调，具体取决于它是视频还是图片。

我正在使用回形针来处理上传过程，我的想法是在上传文件并使用它创建资产时，应用程序将根据上传文件的 mime 类型实例化正确的子类（ Picture或Video ） .

这是我的课程的草图：

我的想法是在Asset类上实现before_save回调并尝试在那里实例化正确的类，但我不知道该怎么做或者这是否是个好主意。

对此有任何想法吗？

这类似于 STI 和 form_for 问题，但那里给出的答案与 rails 3 不兼容，并给出了弃用警告。但是，如果我尝试使用新语法，我会得到一个非常混乱的结果。这就是问题所在。

event_enquiry 是一种查询，在旧语法中我会这样做

这会生成预期的路径 /event_enquiries/1/build_provider_versions 并在日志中我看到 Started POST "/event_enquiries/1/build_provider_versions" for 127.0.0.1 at 2010-12-22 22:00:11 +0000

但这给出了弃用警告

但是虽然新的语法

似乎生成了相同的路由，并且在日志中我得到完全相同的消息 Started POST "/event_enquiries/1/build_provider_versions" for 127.0.0.1 at 2010-12-22 22:01:58 +0000 该路由显然不存在！

ActionController::RoutingError（没有路由匹配“/event_enquiries/1/build_provider_versions”）：

我来来回回地经历了这个，看不到发生了什么。有谁知道发生了什么？

显然，我现在很高兴回到旧语法，但我有一种讨厌的感觉，这里有些东西坏了……还是我只是愚蠢？

这是我面临的情况：

可以安排约会：

1. 今天
2. 一周中的某个时间
3. 在特定日期

因此，每个约会“类型”的属性可能不同。

我正在考虑这些模型并将其与 STI 一起使用，但我不确定我是否走在正确的轨道上：

桌子：

对此进行建模的最佳方法是什么？

这是单表继承的好选择吗？

更新

感谢@Mike，@SpyrosP 到目前为止的帮助。我想出了下面的选项。

这些是数据库表的“视图”以及它们的外观。

哪一个看起来最合适？

我的 Rails 应用程序中有 STI 模型。祖先模型对validates_...运行良好的方法进行了验证。

但我也有自定义验证，我想在后代中添加更多不同的自定义验证。这些自定义验证将取决于类。

如果我写

它只是覆盖了原始验证，因此我放弃了原始继承的验证。

在 Rails 中有这样的约定吗？

我想我需要在 Rails 中使用 STI。

这是我的课：

people 表有一:type列是字符串。

所以，我期望在表中看到的是，作为 Person 的每一行的类型都设置为“Person”，每个 Landlord 的类型都设置为“Landlord”。然而，这不是我所看到的。每个 Landlord 的类型设置为“Landlord”，但所有 Person 的类型都设置为 nil。这很可能是 rails 的工作方式，但我只是在寻找一些确认。

您好，我一直在寻找解决此问题的方法。使用 Rails 2.3.5

我有一个包含几个子类的父类，为了没有一个 1500 行长的文件，我将子类保存在 app/models 目录的子目录中。

直到最近，当我查看这篇文章时：这里

我什至无法加载子类

现在我想使用 self.inherited 类方法访问每个孩子，如下所示：

暂时，我放了一些调试语句来更好地了解事物是如何加载的。我启动了控制台并注意到了这种行为：

我确信对此没有那么优雅的解决方案，例如将子类全部放回一个巨大的文件中，但如果可能的话，我想避免这种情况。

谢谢

也许 STI 不是我想要的，我愿意接受所有建议，但为了这个问题，让我们假设以下现实世界的情况：

您希望您的应用程序为不同的邮件供应商提供 API 数据。使用 STI，您有以下模型

现在让我们启动一些控制台操作：

好的，现在您要添加 API 密钥设置。MailChimp 只使用一个 api_key。Aweber 可以使用 api_key 和签名，而 Postageapp 使用 api_key 和令牌系统。

您会扩展每个子类以包含数据库中所需的任何列吗？你会一起废弃 STI 并让常规类说，MailChimp继承自 AR 吗？

我对 STI 的理由是我知道我的所有用户都会有一个 MailSetting，它是随着时间的推移可能会扩展的类型。但是，我发现以这种方式扩展这些子类很痛苦，因为你不能在user.mail_setting.connect不知道它们来自哪个子类的情况下做一些事情，然后，我需要什么来连接这些人？

想法？

以前，我问过这个关于 ActiveRecord 中多态外键的复合索引的问题。我的问题的基础是我理解索引应该基于列的基数，并且 Rails 的 STI 类型和多态 _type 列的基数通常很低。

接受我的问题的答案是正确的——这就是索引高基数 _id 列和低基数 _type 列的价值，因为它们在一起具有高基数——我的下一个问题是：你应该如何订购你的化合物索引？

[owner_id, owner_type] 的索引将具有较高基数的字段放在第一位，而 [owner_type, owner_id] 将具有较高基数的字段放在第二位。使用前一个键的查询比使用后一个键的查询性能更高，还是它们的性能相同？

我问是因为这与我如何为服务 STI 模型的表订购复合键有特殊关系。STI Rails 查找器几乎总是在类型列上进行查询——这又是一个通常低基数的列。因此，类型列的查询比其他索引更频繁。如果更频繁地查询类型列，那么使用类型前导索引可能是有意义的，因为不太具体的查询可以利用索引的第一部分来提高性能。但是，我不会因为不利于高度特定查询的性能而降低福利。利用索引的较高基数部分。

关于 Rails 3 中的多表继承，是否有标准或最佳实践？到目前为止，我能找到的最好的文章是：

http://mediumexposure.com/multiple-table-inheritance-active-record/

但即使这样也需要一些更改（例如，将需求移动到初始化程序而不是旧的 /config/environment.rb）

有更好的资源/标准吗？