如何在Rails应用程序中组织高级SQL

Question

在Rails应用程序中组织更高级（因此更复杂和更大）的SQL查询有哪些选项？

目的：

• 将SQL和相关规范保存在传统位置。
• 将更大，更可重用的SQL提取到SQL函数，视图，触发器（如何维护funcs的代码，然后是视图？迁移可能不是最佳选择）
• 重用SQL的一部分作为AR的一部分，或作为独立的部分重复使用。
• 利用大部分底层数据库功能（例如PostgreSQL CTE，FTS，扩展等）。
• 保持SQL可管理，可维护。

Answer 1

我会考虑将所有内容打包为独立的gem / Rails引擎。

所有必要的自定义SQL迁移（用于创建视图，函数，存储过程等的代码）都可以放在/db/migrations/sql中，并且可以编写自定义Rake任务来运行这些迁移。

然后，您可以编写各种测试/规范来练习特定于数据库的视图，函数，存储过程等。

此gem将拥有自己的源存储库，并且可以拥有自己的生命周期/发布周期，所有这些都与您的主应用程序无关。可以想象，它可以由一对Ruby专家（用于gem，specs，库）和一个SQL专家（显然）组成。

如果这个库/ API编写得很好，这将为您提供从低级别，特定于数据库的代码中抽象主应用程序的额外好处。也就是说，应用程序开发人员只需要担心调用Widget.complex_sql_query并处理其返回值而不必担心维护它。相反，数据库后端团队不必过多担心他们的代码是如何使用的 - 只要两个团队都同意API合同并且所有测试覆盖范围都很好。

这可以通过主应用程序不可或缺的所有代码完成，但将所有内容作为一个单独的宝石强加了物理和心理障碍，让两个团队更容易专注于各自的责任区域。