В каком месте лучше разместить длинный sql в проекте?

Question

[itcoder]

Имееться:
- php MVC самописанный фреймворк для проекта.
- БД (PostgreeSql)
В проекте часто используються сложные выборки с LEFT JOIN и агрегирующими функциями, вложенными запросами и MATERIALIZED VIEW.
От QueryBuilder было решено откаказаться, при таких длинныз запросах его испозльзовать показалось сложным.
Используем PDO.
Посоветуйте в какое место лучше выносить SQL код, с последующим удобным к нему доступом, чтобы не писать его в контроллере или не раздувать модели функциями в которых будет написан SQL ?

Пример кода:

WITH events AS (SELECT "id","time","Seria__id","url","Event_Type__id" 
FROM "event" WHERE "time">? AND "Event_Status__id"=?)
                   SELECT "e"."id" AS "event.id",
                    min("e"."time") AS "event.time",
                    min("e"."Seria__id") AS "event.Seria__id",
                    min("e"."Event_Type__id") AS "event.Event_Type__id",
                    min("e"."url") AS "event.url",
                    array_to_string(array_agg("p"."name" ORDER BY "e_p"."owner" DESC),?) AS "partaker.name",
                    array_to_string(array_agg("p"."orig_url" ORDER BY "e_p"."owner" DESC),?) AS "partaker.orig_url",
                    array_to_string(array_agg("p"."small_url" ORDER BY "e_p"."owner" DESC),?) AS "partaker.small_url",
                    min("p_e"."price_rub") AS "product_event.price_rub",
                    min("p_e"."analytics") AS "product_event.analytics",
                    min("p_e"."id") AS "product_event.id",
                    min("o"."id") AS "order.id"
                FROM "events" "e"
                LEFT JOIN "event_partaker" "e_p"
                    ON "e"."id"="e_p"."Event__id"
                LEFT JOIN "partaker" "p"
                    ON "p"."id"="e_p"."Partaker__id"
                LEFT JOIN "product_event" "p_e"
                    ON "e"."id"="p_e"."Event__id"
                LEFT JOIN "order" "o"
                    ON ("o"."model_id"="p_e"."id" AND "model_name"=? AND "paid"=1 AND "User__id"=?)
                WHERE "p_e"."active"=1
                GROUP BY 1
                ORDER BY "event.time

Answer 1

[Дмитрий Миронов]

Как вариант Table Data Gateway

Comments

[itcoder]

Идея нравиться, подскажите как лучше оргнизовать классы шлюзов ?
Положить в отдельную дирекрию от моделей ?
И я так понимаю шлюз это абстрактынй класс ?

[Дмитрий Миронов]

Я организую их точно так же как модели, названия как у табличек и прочее.

Положит рядом с моделями.

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

[itcoder]

Дмитрий Миронов: Спасибо, Получаеться модель наследует шлюз, все обращения к клюзу через модель ?. Методы шлюза у вас возращают готовый SQL, а параметры передаваються как аргументы или массив.

[Дмитрий Миронов]

itcoder: Модель не наследует шлюз. Шлюз это отдельный класс, со своей логикой, который возвращает данные для модели.

Answer 2

[Шаров Дмитрий]

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

Comments

[Шаров Дмитрий]

Хотя думаю тоже своего рода костыль

[FanatPHP]

Офигеть совет. Какая там декомпозиция, какой single responsibility? Вали всё в кучу! А потом по контрол-Ф искать свои запросы.

Answer 3

[FanatPHP]

не раздувать модели функциями в которых будет написан SQL ?

Я правильно понимаю, что эта фраза подразумевает, что
а) раздувать надо какую-то другую сущность?
б) предполагается, что для SQL запросов существует более подходящая сущность, чем модель?