Тут вряд ли будет какой-то выйгрыш по скорости, так как все join'ы всеравно будут выполняться аналогичным образом. И если у вас разные таблицы в зависимости от того что выбираем, можно не джойнить все зависимые, а только нужные, то в случае со view вы будети обращаться ко всем таблицам каждый раз.
Про выйграш в скорости — имелось ввиду отказ от использования методов joins/include activerecord. Но в основном мне хотелось показать, как облагородить такой большой запрос, добавив в него частичку магии activerecord. А насчет подключать только нужные таблицы — я брал ситуацию, когда необходимо все. Это может быть поиск по любому столбцу, экспорт в csv/xls…
> После создадим модель Product, сделав ее readonly
т.е. Вы полностью отказываетесь от create/update/delete?
Или Вы дублируете модельками Item/Color/Store/etc?
В данном случае наша модель является в большей степени презентером или декоратором уровня базы данных/модели. А для наполнения информацией используются стандартные модели Item/Color/Store/etc
а бизнес логика в модели — это rails way? Кажется для бизнес логики есть папка lib, а модели всего лишь получают данные из хранилища(базы данных, xml, etc). Хотя возможно, я ошибаюсь))
что значит нельзя получить информацию с присоединенных таблиц? нельзя сделать product.store_name? но можно product.store.name (лишнего запроса в БД все равно не будет)
Несколько месяцев назад была похожая проблема, решили все через pure ruby class. Ваше решение выглядит более элегантней. Сейчас бы точно его использовал, но увы очень много нужно переписывать
Многотабличные модели в Ruby on Rails