14

所以我们都知道 Rails 的 STI（单表继承）是 icky，因为它会导致数据模型混乱和数据库不理想。

然而 PostgreSQL 似乎非常漂亮地处理继承！

有没有办法在利用 Postgres 继承而不是痛苦的宽表和“类型”列的同时获得 rails 干净的 STI API？

4

2 回答 2

8

然而 PostgreSQL 似乎非常漂亮地处理继承！

真的吗？你仔细看说明书上的小字了吗？例如：

  • 唯一约束（因此也是主键）在继承级别上是不可能的。
  • 对继承表和基表的引用不混合。即（大致取自手册）：capitalsextends cities。您的address表要引用cities. 它可以。capital但是可以使用带有a的no地址。

这两件事在小型“Hello World”项目之外的任何事情中都非常重要。所以我无法想象，任何有成效的事情都可以使用 PostgreSQL 继承来实现。

于 2012-04-18T17:29:04.040 回答
5

简而言之 - 没有漂亮干净的 STI API 可以用于您现在尝试完成的工作。

实际上，大约一年前我对此进行了研究，并得出结论认为这不是一个好主意，原因如下：

  1. 如果您想利用 PostgreSQL 的特定功能 - 您基本上就是将自己嫁给了那个数据库。不要误会我的意思，PostgreSQL 是一个很棒的数据库，我已经用过很多次了，但是你会被那个数据库和应用程序设计所困。
  2. 最有可能的是，如果您开始使用 DB 特定功能，您最终要么手动实现它们（在 DB 上运行某种命令或使用 GUI），要么编写某种脚本，当您运行 db:migrate 时必须调用这些脚本（如果你想进行适当的测试，你必须这样做）。一段时间后，它变得繁琐和烦人。
  3. 如果你发现你越来越恼火，引用你“痛苦的宽表和”类型“列” 然后：
    • 您的餐桌设计需要重新考虑和重做
    • 您的模型可能不适合 STI
    • 你只需要忍受它。

大多数 IT 问题实际上都归结为：努力与收益。

在您的情况下，您应该问自己这个问题：

  • 如果它只会将原始 SQL 查询速度提高几秒钟，那么您想花多少时间来实现更好的 STI 结构？也许写一个更明确的 SQL 查询会更好？大多数应用程序不会增长到真正成为问题的大小。但在你的情况下可能会有所不同。

PS：

还有一个关于在您的应用程序中构建 STI 的快速提示：如果您发现有很多使用 STI 的模型，例如 ProductCategory、CommentCategory、PhoneCategory、ClientCategory，它们都继承自 Cateogory - 我倾向于将它们组织在模型目录内的文件夹中。然后在application.rb中添加一行：config.autoload_paths += Dir[Rails.root.join('app', 'models', '{**/**}')]

于 2012-04-18T16:07:27.333 回答