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