我应该如何在Rails中组织复杂的SQL视图？

Question

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

我写了许多视图（SQL类，而不是Rails HTML / ERB类），以使他们期望的输出成为现实。其中一些观点非常庞大，背后有相当大的复杂性。我在SQL中编写它们是因为有许多计算和比较更容易用SQL完成。它们当前直接从名为views.sql的文件加载到数据库中。要获取请求的数据，我执行select * from my_view;。

views.sql文件变得非常大。问题的一部分是我们仍然在弄清楚我们收集的数据意味着什么，所以一直在对视图进行很多改变 - 并且正在创建大量的视图。其中许多都需要重复。

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

我想到的一些选项：

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

您如何应对这样复杂的报告问题？

MladenJablanović的

更新

首先是出于报告目的而提出了几个观点。我的老板决定他们想要更多，所以我开始写更多。根据我给出的要求，有些人会提供几百列数据。

我现在已将几千行视图全部压入一个文件中。我不喜欢这种情况，所以我想重新组织/重构代码。我还想要一种提供CSV的简单方法 - 我正在运行查询并手动通过电子邮件发送，这很容易实现自动化。最后，我希望能够对视图的输出进行一些测试，因为已经出现了几个回归。

Answer 1

我没有直接使用SQL和视图，所以我无法帮助你，但你可以在视图之上构建一个ActiveRecord模型，实际上非常容易。 Enterprise Rails一书有一整章（here it is at Google Books）。

Answer 2

我们正在广泛使用我们的数据库中的视图，其中一些被公开为Rails模型。你可以像使用表一样使用它们，除非你当然不能更新它们。

此外，可以使用其他列（例如，不同的比率）计算某些列，因此我们不在视图中执行此操作，而是在模型中执行（确定，不完全正确，我们构造SQL片段并传递它是:select => ''调用的find部分。

表示逻辑（例如日期和数字格式）转到Rails视图。

我担心我无法帮助你提出更具体的建议，因为问题的范围很广。

修改：

数百列听起来不合理。听起来像是一个地方的大量数据。他们如何使用它？我们有Web应用程序，他们可以向下钻取并过滤结果，缩短时间跨度和时间步长等，因此报告中的列数不会超过10-20列。

我们将每个SQL文件的视图存储为一个视图。此外，您可以将其与数字前缀组合以确保正确的创建顺序（如果其中一些依赖于其他顺序）。没有迁移，整个数据库层都是应用程序无关的。

对于CSV，您可以创建一组可以手动调用或使用cron调用的脚本，也可以使用Rails应用程序中的FasterCSV并通过HTTP请求生成CSV。