Comments 18
Тут вряд ли будет какой-то выйгрыш по скорости, так как все join'ы всеравно будут выполняться аналогичным образом. И если у вас разные таблицы в зависимости от того что выбираем, можно не джойнить все зависимые, а только нужные, то в случае со view вы будети обращаться ко всем таблицам каждый раз.
Про выйграш в скорости — имелось ввиду отказ от использования методов joins/include activerecord. Но в основном мне хотелось показать, как облагородить такой большой запрос, добавив в него частичку магии activerecord. А насчет подключать только нужные таблицы — я брал ситуацию, когда необходимо все. Это может быть поиск по любому столбцу, экспорт в csv/xls…
Вместо
ActiveRecord::Base.connection.execute
в миграциях можно писать просто execute
А вообще во вью можно вставлять записи, правда обработку вставок придется на триггерах описать. Так будет выглядеть совсем как обычная таблица.
> После создадим модель Product, сделав ее readonly
т.е. Вы полностью отказываетесь от create/update/delete?
Или Вы дублируете модельками Item/Color/Store/etc?
т.е. Вы полностью отказываетесь от create/update/delete?
Или Вы дублируете модельками Item/Color/Store/etc?
создание sql представлений — это перенос бизнес-логики из модели в субд. Не rails-way.
А что мешало просто создать named_scope с нужными объединениями?
Scope не дает возможности получить информацию с присоединенных таблиц. Плюс размера scope обычно не более 80 символов, тут же их значительно больше.
Несколько месяцев назад была похожая проблема, решили все через pure ruby class. Ваше решение выглядит более элегантней. Сейчас бы точно его использовал, но увы очень много нужно переписывать
Sign up to leave a comment.
Многотабличные модели в Ruby on Rails