ruby on rails 中多个资源和一个数据库表的最佳实践？答案

【问题标题】：Best practice for multiple resources and one database table in ruby on rails?ruby on rails 中多个资源和一个数据库表的最佳实践？
【发布时间】：2013-04-16 16:14:18
【问题描述】：

我正在开发一个 Ruby on Rails 项目。该项目有一个名为“Post”的主数据库表。

此表用于将问题、答案、cmets 和公告存储为不同的帖子类型。目前我们只使用一种模型来访问数据。但是在系统上工作时感觉很混乱。因为每种帖子类型都有一些差异。

最佳做法是什么：

将 post 资源拆分为不同的资源，但只使用一个 Post 表进行数据访问？
将数据库表拆分为cmets、questions、answers和announcements表；并为每个表使用资源（模型+控制器+视图）？

【问题讨论】：

好吧，我认为您的问题不会被接受，因为不够具体。无论如何，我认为在数据库中反映您的数据总是更好，特别是如果存在（或将会存在）许多差异。但是有不同的查看方式：例如，您可以将公共数据存储在 1 个主表中，并将属性作为键/值对存储在另一个表中。或者按照您的建议为每种数据类型设置不同的表...

标签： ruby-on-rails database model-view-controller

【解决方案1】：

简短回答：视情况而定。

您现在所做的非常接近单表继承 (STI)，尽管听起来您使用的是包含所有不同行为的单个 Post 类。 STI 是一种存储模型数据的有效方法，但与所有事物一样，它也有优点和缺点。

我的建议是使用单独的类来封装单独的域模型的行为。这是 OOP 的基本范式，所以我会说它可能是最佳实践。

假设您将行为拆分到各个类中，您是使用单个表还是多个表来存储它们的问题实际上取决于查询的复杂性以及模型中有多少公共字段。如果他们有很多共同的领域，STI 可能会很好地工作。如果没有，您可能不会享受您将支付的所有额外读取/写入的开销。但所有这些都是次要的，可以随着您的应用程序的发展以及您对使用模式的了解更多而弄清楚。

使用 STI 尝试一下，看看效果如何。将事物拆分为多个表比相反更容易，因此迁移路径不一定太难。

【讨论】：

谢谢。这是一个很好的建议。我列出了每种帖子类型之间的结构差异，我认为使用一个表仍然有用。根据帖子类型，只有 1 或 2 个空列。我认为现在还可以。
对于那种程度的重叠，是的，我同意，您可能可以使用 STI。请记住，您仍然可以使用资源丰富的路由/控制器，但您的控制器可以继承自一个通用控制器。有很多方法可以在此设置中保持干燥。从长远来看，您可能最终会打破局面，但这很难预测。它可能永远没有必要。

【解决方案2】：

我认为选择应该基于每一个特定的情况。只需为您列举每个选项的优缺点。调查和决策的要点可能是：每种类型实体之间的差异数量、访问实体的方式、每种类型实体的使用频率、代码的可维护性、未来变化的预测等等。

【讨论】：