ActiveRecord中的PostgreSQL继承？

Question

所以我们都知道rails的STI(单表继承)很糟糕,因为它会导致混乱的数据模型和次优的数据库.

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

有没有办法在使用Postgres继承而不是痛苦的宽表和"类型"列的同时获得rails'漂亮干净的STI API？

Answer 1

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

真？您是否仔细查看了手册中的小字？例如:

• 在继承级别上不可能有唯一约束(因此也是主键).
• 对继承表和基表的引用不会混淆.即(大致取自手册):capitals延伸cities.你的address桌子想要参考cities.它可以.但是capital可以使用带有a的无地址.

除了一个小的"Hello World"项目之外,这两件事非常重要.所以我无法想象,使用PostgreSQL继承可以实现任何高效的工作.

Answer 2

简而言之 - 没有很好的干净的 STI API 来满足您目前要完成的任务。

大约一年前，我实际上对此进行了调查，并得出以下结论：由于以下几个原因，这不是一个好主意：

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

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

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

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

PS：

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