@beduin01

На сколько правильно разбить один запрос на три более маленьких?

Есть три логических блока (условно ) A B C.
Каждый логический блок состоит из 3-7 таблиц.
По хорошему у всех трёх блоков есть какой-то общий ключ.
Я могу написать большой SQL селект который все данные сджойнит и вытащит, НО:

1. Не всегда есть возможность для блока А найти данные в таблицах группы B и С.
2. Запрос на джоин получается реально очень громоздким.
3. Надо иметь возможность относительно безболезненной возможности расширять логику запроса.

Я думаю может стоит делать три раздельных запроса, отображать на клиенте в единой таблице по мере их выполнения и в случае чего так же иметь возможность написать какую-то логику обработки блоков если к примеру данных для блока А не нашлось, но неожиданно есть B и С.

Какие минусы у подобного подхода будут? Так вообще делают?

Я реально не пойму как в рамках одного большого запроса обрабатывать разные расширенные условия выборки.

БД PostgreSQL.
  • Вопрос задан
  • 52 просмотра
Пригласить эксперта
Ответы на вопрос 2
@basili4-1982
насчет разбивать не разбивать не скажу. Тут надо профилировать запросы. А вот Я реально не пойму как в рамках одного большого запроса обрабатывать разные расширенные условия выборки. Тут вот как делают. 1 делают общую вьюху и по ней уже фильтруют нужные поля.
Ответ написан
Комментировать
@mayton2019
Bigdata Engineer
Если ты разбиваешь 1 запрос на 3 мелких - то тебе нужно оборачивать их транзакцией или доказывать что между запросами не будет посторонних модификаций данных. Иначе 3 запроса не будут эквивалентны первому. Это кстати типичная джуниорская ошибка - неучет ACID.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы