Как мне организовать сложные представления SQL в Rails?

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.)

Как бы вы справились с такой сложной отчетной проблемой, как эта?

ОБНОВЛЕНИЕ для Младена Яблановича

Это началось с того, что у нас было несколько представлений для отчетности. Мой начальник решил, что они хотят большего, поэтому я начал писать больше. Некоторые дают пару сотен столбцов данных, основываясь на требованиях, которые мне дали.

Теперь у меня есть пара тысяч линий просмотра, которые объединены в один файл. Мне не нравится такая ситуация, поэтому я хочу реорганизовать / реорганизовать код. Я также хотел бы получить простой способ предоставления CSV - в настоящее время я выполняю запросы и отправляю их по электронной почте, что может быть легко автоматизировано. Наконец, я хотел бы иметь возможность написать несколько тестов для вывода представлений, так как пара регрессий уже появилась.

Answer 1

Я не очень много работал с SQL и представлениями напрямую, поэтому не могу вам помочь, но вы, безусловно, можете построить модель ActiveRecord поверх представления, на самом деле очень легко. В книге Enterprise Rails есть целая глава ( здесь, в Google Книгах ).

Answer 2

Мы широко используем представления в нашей БД , и некоторые из них представлены в виде моделей Rails. Вы работаете с ними так же, как с таблицами, за исключением того, что вы, конечно, не можете их обновить.

Кроме того, некоторые столбцы могут быть рассчитаны с использованием других столбцов (например, с другими соотношениями), поэтому мы не делаем это в представлении, а вместо этого в модели (хорошо, не совсем верно, мы создаем фрагмент SQL и передаем это :select => '' часть звонка find).

Логика представления (например, форматирование даты и чисел) переходит к представлениям Rails.

Боюсь, я не могу помочь вам более конкретным советом, поскольку сфера вопроса довольно широка.

EDIT

Сотни колонок не звучат разумно. Похоже, огромное количество данных в одном месте. Как они вообще это используют? У нас есть веб-приложение, в котором они могут развернуть и отфильтровать результаты, сузить временной интервал, временной шаг и т. Д., Поэтому в отчетах никогда не бывает более 10-20 столбцов.

Мы храним наши представления по одному представлению на файл SQL. Кроме того, вы можете комбинировать его с числовым префиксом, чтобы обеспечить правильный порядок создания (в случае, если некоторые из них зависят от других). Там нет миграций, весь уровень БД не зависит от приложения.

Для CSV вы можете создать либо набор сценариев, которые вы можете вызывать либо вручную, либо с помощью cron, либо вы можете использовать FasterCSV из приложения Rails и генерировать CSV по HTTP-запросу.