heartdevil: Да мне кажется имеющейся информации вполне достаточно. По крайней мере в ответах есть что-то интересное (concat), попробую пока с этим разобраться. Если не получится, дополню вопрос. Если получится, отпишусь, как получилось.
К тому же, в том-то и дело, что я не совсем понимал как может/должен выглядеть результат в данном конкретном или общем случае.
Только нужно быть аккуратным при использовании ORM в циклах. Обязательно следите за количеством запросов. В сложных списках как правило оптимальнее будет получать данные одним сложным запросом.
А если в конце добавить GROUP BY Request.r_id ? В любом случае, направление я вам указал, дальше думаю не трудно должно быть. Я вполне мог и опечататься где-то. Можете попробовать убрать LEFT в джойнах.
Не код и не сами запросы. Просто когда количество запросов на странице переваливает за 500 средствами ORM, начинаются проблемы. А в коде все красиво и понятно.
Не уловил, к чему тут намек про join, но я знаю, что это такое. Говоря про "не очень хорошо знаю SQL" я не совсем это имел в виду.
Кому не нужна скорость? Разработчикам? Согласен полностью. Клиентам? У них пробовали спросить? Если страница рендерится на бэкенде более 10 секунд, я считаю, что это повод задуматься об оптимизации скорости. Вы не согласны?
В общем случае активно пользуюсь такой схемой, к примеру, в характеристиках товаров в каталоге. Правда, не понял, чем у вас отличаются VALUE от ACTUAL. Можете пояснить?
По поводу скорости, все-таки 2 джойна будут тяжелее, чем их отсутствие, на мой взгляд.
В итоге я решил применить смешанную схему: динамическое добавление для действительно динамических вещей (диапазоны цен заказов и прочее) и добавление постоянных свойств (дни недели и прочее) в таблицу пользователей. Скорость работы тоже важна, так что "будем посмотреть", как пойдет :)
Всем спасибо за ответы!
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
