ruby-on-rails - Ruby on Rails - STI 的替代品？

Question

我有许多不同的模型(接近 20 个)，它们共享一些共同的属性，但在其他方面也有一定程度的不同。 STI 起初看起来很有吸引力，但我不知道随着时间的推移，随着产品的快速开发，各种模型将如何演变。

想到的与我们的应用程序很好的相似之处是 Yelp。 Yelp 如何在 Rails 中管理某些东西？所有的帖子都有一些共同的属性，比如“地址”。然而，他们在其他方面有很大不同。例如，您有餐厅预订选项，而其他人可能没有预订选项。餐馆还有许多其他属性，例如“允许饮酒”，这些属性不适用于其他人。用 STI 这样做会很快失控。

那么下一个最佳选择是什么？使用 Postgres 的 HStore？我不习惯将 HStore 用于除小事之外的任何事情。 HStore 解决了一些问题，同时引入了其他问题，例如缺少数据类型、缺少引用完整性检查等。我想要一个可靠的关系数据库作为构建的基础。所以在 Yelp 的案例中，我要去的地方可能是餐厅模型。我看过像这里这样的建议 - http://mediumexposure.com/multiple-table-inheritance-active-record/ ，但我不乐意做这么多的猴子补丁来获得如此普遍的东西。

所以我想知道还有其他替代方案(如果有的话)还是我应该咬紧牙关，咬紧牙关，将这些共同属性复制到 20 个模型中？我认为我的问题来自迁移文件而不是代码本身。例如，如果我将迁移设置为循环遍历表并在表上设置这些属性，那么我是否可以通过使用不同的模型来减轻问题的严重程度？

我是否忽略了一些关键的东西，这些东西可能会在使用单独的模型时导致大量问题？

Answer 1

我在这里看到几个选项:

咬紧牙关，创建具有许多相同属性的 20 个不同模型。随着时间的推移，这些模型可能会发生变化 - 向一种特定类型添加新字段 - 您将使用 STI 创建一个 200 列的表。也许你没有 - future 很难看到，尤其是对于探索性/敏捷软件。

将非引用字段存储在 NoSQL(文档)数据库中。将关系数据库用于关系记录的部分(用户有很多评论，评论有一个业务)，但将特定于类型的内容保存在 NoSQL 数据库中。保留 external_document_id在您的 Rails 模型和 external_record_id 中/external_record_type在您的 NoSQL 文档架构中，因此您仍然可以使用您最终使用的任何 NoSQL ORM 查询所有允许吸烟的条。

创建一个属性模型。一个属性 belongs_to :parent_object, polymorphic: true与 key和 value field 。通过这种方法，您可能有一个基础 Business型号及各业务均可has_many :attributes .业务 ( allows_smoking ) 的某些(非关系？)属性是一个 Attribute记录。安 Attribute的键可以是字符串，也可以是您拥有 Ruby 常量的数字。您实际上是在使用 Attribute实体来创建选项 #2 的 SQL 版本。这可能是一个不错的选择，我自己已经将它用于 User 或 Profile 模型。 (尽管使用这种方法有一些性能问题需要注意)。

我真的很担心有那么多(独立的)模型来制作听起来像子类的东西。通过使用 Concerns(混合概念上的语法糖，请参阅 awesome SO answer on concerns in Rails 4)，您可能能够消除常见的行为/方法。当然，您仍然有(初始)迁移问题。