我应该如何在rails中组织复杂的sql视图?

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

我已经编写了许多视图(sql类,而不是rails html/erb类)来实现它们期望的输出。其中一些观点相当大,背后有相当多的复杂性。我用sql编写它们是因为有很多计算和比较是用sql更容易完成的。它们当前直接从名为 views.sql . 为了得到请求的数据,我做了一个 select * from my_view; .

这个 查看SQL 文件越来越大了。问题的一部分是,我们仍然在弄清楚我们收集的数据意味着什么,所以一直以来视图都在做很多更改,其中很多正在创建。其中许多需要可重复。

我最近遇到了一些问题 组织 和 测试 这些观点。rails在用户界面和业务逻辑方面工作得很好,但我不知道有多少现有的结构可以处理我们需要的报告。

我想到了一些选择:

• 我应该把它们移到最相关的模型中吗?有几个视图相互作用,这使得这种情况比单独执行一个视图更复杂 find_by_sql ,所以我不知道它们是否应该只是模型的一部分。
• 也许他们 应该 被视为MVC意义上的“视图”?(也就是说,他们可以搬进 app/views/ 并与html一起生活,也许作为文件命名类似 my_view.csv.sql 返回csv。)

你会如何处理这样一个复杂的报告问题?

更新 为Mladen Jablanovi_

它首先有几个用于报告目的的视图。我的老板认为他们想要更多,所以我开始写更多。有些人根据我的要求给出了几百列数据。

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