Почему одно объединение "умное", но медленное, другое - "тупое", но честное?

Обсудим сегодня эту тему.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

UNION и UNION ALL.

На вид - почти одно и то же.
По смыслу - разные вещи.

И вот почему

UNION ALL — «тащит всё как есть»

UNION ALL просто берёт результаты двух запросов и клеит их друг под другом:

SELECT name FROM customers

UNION ALL

SELECT name FROM partners;

Никаких проверок, дубликатов, умностей.

- Если в обоих списках есть «Иван», то итоговый результат будет два «Ивана».
- Если порядок в исходных таблицах хаотичный, в результате он будет ещё хаотичнее.

UNION ALL = быстро + честно + без фильтров.

UNION - «умный, но медленный»

UNION делает то же самое, но перед тем как вернуть результат, он удаляет дубликаты:

SELECT name FROM customers

UNION

SELECT name FROM partners;

Чтобы убрать дубли, PostgreSQL/Oracle/MySQL вынуждены:

• отсортировать результат

• или построить hash-сет

• и только потом вернуть данные

Это дорого.
На миллионах строк может стать тормозом №1 в отчёте.

UNION = красиво, чисто, но медленно.

Где использовать UNION?

✔ Когда действительно нужны уникальные значения

Например, получить список всех пользователей, независимо от источника:

SELECT user_id FROM old_system

UNION

SELECT user_id FROM new_system;

✔ Когда нужно исключить дубли после сложной логики

Например, когда запросы пересекаются, а ты не хочешь вручную писать DISTINCT.

Где использовать UNION ALL?

Практически везде, там где не надо удалять дубликаты, т.к. их по определению нет.
Например объединение отчетных данных за разные периоды.

SELECT * FROM sales_2024

UNION ALL

SELECT * FROM sales_2025;

Неочевидный факт: порядок строк не гарантируется

Ни в UNION, ни в UNION ALL.

Если хочешь порядок — дописывай: ORDER BY

Вывод:

• UNION ALL — как корзина: «скидываем всё подряд».

• UNION — как фильтр: «скидываем всё, но потом отбираем уникальное».

Мой канал На связи: SQL ждет тебя, если ты тоже хочешь познакомиться с базовым языком для аналитики данных. Подписывайся!

Итак, решение найдено с помощью очень хорошего и талантливого человека, который тоже есть на Пикабу, но свело нас не Пикабу, а творчество. Огромное спасибо ей и за решение, и за творчество! Как и обещал ранее, публикую решение тут, вдруг кому пригодится. Запрос написан очень красиво и понятно, легко разобраться. ИМХО по таким примерам очень удобно изучать SQL. Да и @Avenir.Sirgun хотел взглянуть)))
Итак, вот запрос, который решает:

SELECT

YEAR(R.ДатаРасход) AS Год,

MONTH(R.ДатаРасход) AS Месяц,

A.Адрес,

M.НазваниеМатериал,

SUM(R.КолвоМатериала) AS Количество

FROM Расходы AS R

JOIN Работы AS W ON R.IDРабот = W.IDРабот

JOIN Адреса AS A ON W.IDАдреса = A.IDАдрес

JOIN Материалы AS M ON R.IDМатериала = M.IDМатериал

GROUP BY

YEAR(R.ДатаРасход),

MONTH(R.ДатаРасход),

A.Адрес,

M.НазваниеМатериал

ORDER BY

Год,

Месяц,

A.Адрес,

M.НазваниеМатериал;

Структура БД есть в изначальном посте.
Далее уже можно модифицировать, если надо.
Задача решена! Ура! Ещё раз огромное спасибо, В..., ты очень мне помогла! (не тегаю, т.к. не получал на то дозволения)

Друзья, задумал немного помочь себе и упростить работу. В свободное время решил соорудить базу данных выполненных работ по участку и потраченных на это материалов. Когда-то успешно делал себе "помогалки" в MS Access (в 90ых ещё), поэтому выбрал LibreOffice Base. Структура вот такая:

Форму для заполнения сделал. Заполняется, хранит данные. Отчёт по всем тратам отдельно создать - не проблема, получилось. Это без условий и без формул, просто списком.
Но никак не могу осилить отчёт, в котором бы выдавалась сумма по каждому адресу - сколько потрачено каждого вида материала. Типа,
Май:
Адрес1:
материал1 - 1
материал2 -3
Адрес2:
материал1 - 2
материал3 -4

Гуглил-яндексил, пытался по наитию, ничего не получается. Наверное, если просижу пару недель, изучая всё к ряду, то осилю... но подсказка бы ускорила.
Конечно, без рейтинга. Не знал, в какое сообщество отправить, но, надеюсь, не ошибся, ибо запрос-то на SQL писать придётся))) - долго ждать модерации, публикую без сообщества.
Заранее благодарен!
(Есть и второй вопрос - никак не могу придумать, как сделать типовые работы - чтобы кнопочку нажал, и автоматически заполнились поля формы, создались записи в таблице с расходами материалов)

CASE WHEN - часто используемое условное выражение в запросах. Его особенности и факты далее.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

CASE - возвращает значение, но не управляет логикой выполнения запроса.

SELECT

name,

CASE

WHEN salary > 100000 THEN 'богач'

WHEN salary BETWEEN 50000 AND 100000 THEN 'норм'

ELSE 'бедняк'

END AS category

FROM employees;

Здесь CASE не «делает выборку», а вычисляет новое значение для каждой строки.

Где используется CASE

✅ В SELECT - чтобы выводить вычисленные поля
✅ В WHERE - чтобы сделать фильтрацию условной
✅ В ORDER BY - чтобы сортировать по кастомной логике
✅ В GROUP BY и HAVING - для агрегатов с условиями

Пример в ORDER BY:

ORDER BY

CASE WHEN status = 'vip' THEN 1 ELSE 2 END

В итоге VIP-клиенты окажутся первыми — без лишнего UNION или сортировки по тексту.

Где нельзя использовать CASE

• Нельзя динамически подменять им названия колонок или таблиц — SQL так не работает:

SELECT * FROM CASE WHEN ... THEN table1 ELSE table2 END -- ошибка

• Нельзя изменять структуру запроса — CASE не может выбирать, какие поля попадут в SELECT.

То есть он работает только на уровне данных, не на уровне схемы запроса.

Неочевидные факты

1. CASE возвращает первое совпадение

SQL идёт сверху вниз — как только условие совпало, остальные даже не проверяются.
Поэтому важно порядок условий.

CASE

WHEN score > 80 THEN 'A'

WHEN score > 90 THEN 'A+' -- никогда не сработает

END

Потому что >80 ловит всё, включая >90.

2. Тип результата — общий для всех веток

CASE пытается привести все результаты к единому типу.
Если ты вернёшь 'текст' и NULL, всё ок.
Но если 'текст' и 123, то SQL может выдать ошибку или привести число к строке.
💡 Всегда делай значения одного типа, особенно если потом используешь CASE в арифметике.

3. Есть две формы: сравнительная и поисковая

Обычно используют поисковую:

CASE WHEN condition THEN result ... END

Но есть ещё сравнительная:

CASE status

WHEN 'new' THEN 1

WHEN 'active' THEN 2

END

Она короче, но менее гибкая — работает только с равенством (=).

4. CASE + агрегаты = мощный аналитический трюк

Чтобы посчитать агрегаты по категориям в одной строке:

SELECT

SUM(CASE WHEN gender = 'M' THEN 1 ELSE 0 END) AS male_count,

SUM(CASE WHEN gender = 'F' THEN 1 ELSE 0 END) AS female_count

FROM users;

Один запрос, два счётчика, без подзапросов и джойнов.

5. CASE в WHERE — не всегда оптимален

Когда ты используешь CASE в WHERE, PostgreSQL часто не может применить индекс,
потому что условие становится непредсказуемым.

Пример:

WHERE

CASE WHEN is_vip THEN discount > 10 ELSE discount > 30 END

Лучше выносить логику в OR:

WHERE (is_vip AND discount > 10)

OR (NOT is_vip AND discount > 30)

Так планировщик сможет использовать индексы (их наличие подразумевается)

Где CASE особенно полезен

• Когда нужно сделать динамическую сегментацию данных (категории, статусы, группы)

• При построении витрин и отчётов (разделить аудиторию, выделить группы риска и т.п.)

• Для чистки данных на лету (заменить NULL на текст или дефолтное значение)

• В AB-тестах — присвоить группе метку на основании условия

Если тебе нравятся такие разборы SQL с реальными примерами и подводными камнями —
подписывайся на мой Telegram На связи: SQL

Простые функции. Кажется, что они находят просто минимум и максимум. Но есть и особенность их использования для интерпретации результатов. Об этом далее.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

MIN и MAX — не только про числа

Они работают с любыми типами данных:

• датами (MIN(date) даст самую раннюю дату),

• строками (MAX(name) вернёт последнюю в алфавитном порядке),

• булевыми значениями (MIN(bool) — false, MAX(bool) — true).

Иногда этим можно ловко воспользоваться — например, чтобы узнать, есть ли хоть один true:

SELECT MAX(is_active) FROM users;

Если вернёт true — значит, кто-то активен. Красиво и лаконично.

MIN и MAX — не только агрегатные, но и оконные функции

Можно получить минимум или максимум в рамках окна, не теряя детализацию:

SELECT

user_id,

date,

MAX(date) OVER (PARTITION BY user_id) AS last_activity

FROM logins;

Так можно легко вытащить, когда пользователь последний раз заходил — без группировки и без JOIN.

MIN/MAX и NULL

Они игнорируют NULL.
То есть если у тебя все значения NULL, то результат — NULL.
Это часто ломает аналитику, особенно при сравнении с COALESCE или при объединении данных.

SELECT MAX(COALESCE(score, 0)) -- вернёт 0, а не NULL

→ Иногда важно явно заменить NULL, чтобы не получить "пустой" результат.

MIN/MAX могут ускорить выборку

Если в таблице есть индекс по нужному полю —
MIN() и MAX() используют только крайний элемент индекса.
Это значит, что:

SELECT MAX(price) FROM products;

может пройтись не по миллиону строк, а просто взять последнее значение из B-tree индекса.
То есть — мгновенно.

Можно найти строку с минимальным/максимальным значением

Классическая боль аналитика: как вытащить не просто максимум, а всю строку, где он встретился.

💡 Один из лучших способов — оконная функция + фильтр:

SELECT *

FROM (

SELECT *,

ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn

FROM employees

) t

WHERE rn = 1;

→ Получаем сотрудника с максимальной зарплатой.
Без подзапросов, без JOIN, без боли.

Неочевидный кейс: поиск экстремумов в группах

SELECT department, MIN(salary), MAX(salary)

FROM employees

GROUP BY department;

Классика, но важно:
разница между MAX и MIN = разброс значений, полезный показатель в аналитике (например, зарплат).

💬 Если хочешь больше таких разборов с реальными кейсами SQL без воды — подписывайся на мой Telegram 👉На связи: SQL
Там я рассказываю про SQL так, чтобы стало интересно даже тем, кто раньше его ненавидел 😄