1

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

目的：

  • 将 SQL 和相关规范保存在常规位置。
  • 将更大、更可重用的 SQL 提取到 SQL 函数、视图、触发器中（那么如何维护函数、视图的代码？迁移可能不是最好的选择）
  • 将 SQL 片段作为 AR 的一部分或作为独立的一部分重用。
  • 利用大部分底层数据库功能（例如 PostgreSQL CTE、FTS、扩展等）。
  • 保持 SQL 的可管理性、可维护性。
4

1 回答 1

1

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

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

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

这个 gem 将有自己的源代码库，并且可以有自己的生命/发布周期，所有这些都独立于您的主应用程序。可以想象，它可以由 Ruby 专家（用于 gem、specs、库）和 SQL 专家（显然）组成。

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

这可以通过与主应用程序集成的所有代码来完成，但是将所有内容都作为一个单独的 gem 会带来身体和心理障碍，让两个团队更容易专注于各自的责任领域。

于 2013-01-17T03:18:37.600 回答