На сколько правильно разбить один запрос на три более маленьких?
Есть три логических блока (условно ) A B C.
Каждый логический блок состоит из 3-7 таблиц.
По хорошему у всех трёх блоков есть какой-то общий ключ.
Я могу написать большой SQL селект который все данные сджойнит и вытащит, НО:
1. Не всегда есть возможность для блока А найти данные в таблицах группы B и С.
2. Запрос на джоин получается реально очень громоздким.
3. Надо иметь возможность относительно безболезненной возможности расширять логику запроса.
Я думаю может стоит делать три раздельных запроса, отображать на клиенте в единой таблице по мере их выполнения и в случае чего так же иметь возможность написать какую-то логику обработки блоков если к примеру данных для блока А не нашлось, но неожиданно есть B и С.
Какие минусы у подобного подхода будут? Так вообще делают?
Я реально не пойму как в рамках одного большого запроса обрабатывать разные расширенные условия выборки.
Оба варианта имеют право на жизнь, какой выбрать зависит от многих факторов.
Выбирайте тот, который вы считаете более удобным.
В принципе, 3 запроса увеличат расходы на сетевой лаг, особенно если он у вас большой, но не факт что объединенный в 1 запрос они будут выполняться суммарно быстрее (если этот вопрос важный, то нужно проверять оба варианта). Как тот, или иной вариант скажется на читабельности и расширяемости кода, знаете только вы. Насчет затащить в 1 запрос еще и дополнительную логику зависит от ваших принципов построения архитектуры, зачастую логику стараются держать вне базы, так проще управлять и гораздо легче масштабироваться, ведь база чаще всего самое узкое место. Но есть и адепты все затащить в базу.
насчет разбивать не разбивать не скажу. Тут надо профилировать запросы. А вот Я реально не пойму как в рамках одного большого запроса обрабатывать разные расширенные условия выборки. Тут вот как делают. 1 делают общую вьюху и по ней уже фильтруют нужные поля.
Если ты разбиваешь 1 запрос на 3 мелких - то тебе нужно оборачивать их транзакцией или доказывать что между запросами не будет посторонних модификаций данных. Иначе 3 запроса не будут эквивалентны первому. Это кстати типичная джуниорская ошибка - неучет ACID.
Уверен, что вам поможет выделение отдельных частей запросов в обновляемые по расписанию таблицы(витрины) или представления (view), далее их можно использовать с фильтрами и джойнить между собой.
Простой
