Что альтернативы к find_by_sql для computationaly-тяжелых запросов?

Похоже, ваши таблицы можно нормализовать. В одном месте, где я работал, объем проведенной нами нормализации повлиял на наши потребности в отчетности, поэтому мы создали несколько теневых таблиц, содержащих кучу агрегированных данных, и составили отчеты против них.

Я согласен с комментарием Нила Н. вопрос немного расплывчатый, но, может быть, он поможет вам двигаться в правильном направлении?

Есть ли в ваших отчетах что-либо, что препятствует использованию представления SQL или хранимой процедуры?

В одном конкретном проекте я часто считаю полезным метод, заключающийся в создании запроса SQL ( это может быть довольно сложно) в качестве именованного представления в базе данных, а затем использовать

 YourModel.connection.select_all(query)

для возврата данных. Это не оптимальный подход; Я очень хочу изучить его улучшения.

К сожалению, как вы предположили, поддержка создания сложных отчетов на основе базы данных внутри рельсов кажется довольно ограниченной.

Хотя наше решение не зависит от базы данных, наше решение - это функции plpgsql, где использование Ruby и ActiveRecord становится очень медленным.

Плагин Squirrel от Thoughtbot добавляет множество рубиновых функций к методу find ActiveRecord с многоуровневыми условными выражениями, диапазонами и вложенными ассоциациями моделей:

www.gotitbot.com / projects / squirrel /