sql - 我应该如何在 Rails 中组织复杂的 SQL View ？

Question

我使用 Ruby on Rails 管理一个研究数据库。输入的数据主要供科学家使用，他们更喜欢将研究的所有相关信息放在一个单独的大表中，以便在他们选择的统计软件中使用。我目前将其呈现为 CSV 格式，因为它非常简单易用并且与人们想要使用的工具兼容。

我已经编写了很多 View (SQL 类型，而不是 Rails HTML/ERB 类型)来实现他们期望的输出。其中一些 View 非常大，背后有相当多的复杂性。我用 SQL 写它们是因为有很多计算和比较用 SQL 更容易完成。它们目前直接从名为 views.sql 的文件加载到数据库中。为了获取请求的数据，我执行了 select * from my_view;。

views.sql 文件变得相当大。部分问题在于我们仍在弄清楚我们收集的数据意味着什么，因此一直在对 View 进行大量更改——并且正在创建大量更改。其中许多需要可重复。

我最近遇到了组织和测试这些 View 的问题。 Rails 非常适合用户界面和业务逻辑，但我不知道有多少现有结构可以处理我们需要的报告。

我想到的一些选项:

• 我应该以某种方式将它们转移到最相关的模型中吗？多个 View 相互交互，这使得这种情况比仅执行单个 find_by_sql 更复杂，因此我不知道它们是否应该只作为模型的一部分。
• 也许它们应该被视为 MVC 意义上的“ View ”？ (也就是说，它们可以移动到 app/views/ 并与 HTML 并存，可能作为名为 my_view.csv.sql 的文件，返回 CSV。)

您将如何处理这样复杂的报告问题？

更新 Mladen Jablanović

它首先有几个用于报告目的的 View 。我的老板决定他们想要更多，所以我开始写更多。根据我收到的要求，有些会提供几百列数据。

我现在有几千行 View 都挤在一个文件中。我不喜欢那种情况，所以我想重新组织/重构代码。我还想要一种提供 CSV 的简单方法——我目前正在运行查询并手动通过电子邮件发送它们，这很容易实现自动化。最后，我希望能够对 View 的输出编写一些测试，因为已经弹出了一些回归。

Answer 1

我没有直接使用 SQL 和 View ，所以我不能在这方面帮助您，但是您当然可以在 View 之上构建 ActiveRecord 模型，事实上非常容易。 Enterprise Rails 一书有一整章(here it is at Google Books)。