SELECT і фільтрація

Як побудований запит SELECT?

Мінімальний запит — SELECT і FROM. Решта частин необов'язкові, але пишуться завжди в такому порядку:

SELECT   email, country          -- які стовпці
FROM     users                   -- з якої таблиці
WHERE    country = 'PL'          -- фільтр рядків
GROUP BY ...                     -- групування
HAVING   ...                     -- фільтр груп
ORDER BY created_at DESC         -- сортування
LIMIT    10;                     -- обмеження кількості

-- SELECT * повертає всі стовпці: зручно для дослідження,
-- але в автотестах і звітах краще перелічувати стовпці явно

У якому порядку насправді виконується запит?

Логічний порядок відрізняється від порядку запису:

1. FROM і JOIN — зібрати рядки з таблиць
2. WHERE — відфільтрувати рядки
3. GROUP BY — згрупувати
4. HAVING — відфільтрувати групи
5. SELECT — обчислити стовпці й аліаси
6. DISTINCT — прибрати дублікати
7. ORDER BY — відсортувати
8. LIMIT / OFFSET — обрізати

Звідси практичні наслідки: аліас із SELECT не можна використати в WHERE — на момент WHERE його ще не існує. А в ORDER BY — можна, бо сортування йде після SELECT. І агрегатну функцію не можна поставити у WHERE — для цього є HAVING.

-- помилка: аліас amount_usd ще не існує на етапі WHERE
SELECT amount * 0.25 AS amount_usd FROM transactions WHERE amount_usd > 100;

-- правильно: повторити вираз
SELECT amount * 0.25 AS amount_usd FROM transactions WHERE amount * 0.25 > 100;

-- а в ORDER BY аліас працює
SELECT amount * 0.25 AS amount_usd FROM transactions ORDER BY amount_usd DESC;

Які оператори використовують у WHERE?

• Порівняння: =, <> або !=, >, <, >=, <=.
• Логічні: AND, OR, NOT.
• Множини й діапазони: IN, BETWEEN, LIKE, IS NULL.

Пастка — пріоритет: AND виконується раніше за OR. Без дужок запит може повернути зовсім не те.

-- задумано: невдалі транзакції типу deposit або withdrawal
-- насправді: (deposit) АБО (withdrawal І failed)
SELECT * FROM transactions
WHERE type = 'deposit' OR type = 'withdrawal' AND status = 'failed';

-- правильно
SELECT * FROM transactions
WHERE (type = 'deposit' OR type = 'withdrawal') AND status = 'failed';

Як працюють IN, BETWEEN і LIKE?

• IN — значення входить у список: status IN ('pending', 'failed').
• BETWEEN — діапазон включно з обома межами: amount BETWEEN 100 AND 500 — це >= 100 AND <= 500.
• LIKE — пошук за шаблоном: % — будь-яка кількість символів, _ — рівно один. У PostgreSQL ILIKE ігнорує регістр.

Пастка BETWEEN з датами: created_at BETWEEN '2026-09-01' AND '2026-09-30' для стовпця з часом відріже весь день 30 вересня після 00:00. Надійніше напіввідкритий діапазон.

-- надійно для TIMESTAMP: включно з 1-м, без 1 жовтня
SELECT * FROM transactions
WHERE created_at >= '2026-09-01' AND created_at < '2026-10-01';

-- усі gmail-адреси без урахування регістру
SELECT email FROM users WHERE email ILIKE '%@gmail.com';

Як знайти рядки, де значення NULL?

Лише через IS NULL і IS NOT NULL. Умова = NULL дає UNKNOWN для кожного рядка, тому запит поверне нуль рядків — без жодної помилки. Це особливо підступно: здається, що даних просто немає.

Друга пастка: WHERE status <> 'failed' не поверне рядки, де status — NULL. Якщо вони потрібні, умову треба доповнити.

SELECT * FROM users WHERE phone IS NULL;       -- правильно
SELECT * FROM users WHERE phone = NULL;        -- завжди 0 рядків

-- усі, крім failed, включно з NULL
SELECT * FROM transactions
WHERE status <> 'failed' OR status IS NULL;

-- або в PostgreSQL
SELECT * FROM transactions WHERE status IS DISTINCT FROM 'failed';

Що робить DISTINCT?

DISTINCT прибирає повторювані рядки з результату. Унікальність рахується за всією комбінацією обраних стовпців, а не за першим.

SELECT DISTINCT country FROM users;              -- список країн
SELECT DISTINCT currency, status FROM accounts;   -- унікальні пари
SELECT COUNT(DISTINCT user_id) FROM accounts;    -- скільки користувачів мають рахунок

Як працюють ORDER BY і LIMIT?

• ORDER BY col ASC — за зростанням (за замовчуванням), DESC — за спаданням. Можна сортувати за кількома стовпцями.
• LIMIT n — повернути n рядків, OFFSET k — пропустити k. У SQL Server замість LIMIT — TOP n або OFFSET … FETCH.

Дві пастки:

• LIMIT без ORDER BY повертає довільні рядки. Порядок без ORDER BY не гарантований ніде — тест на «перший запис» буде нестабільним.
• NULL у сортуванні: у PostgreSQL NULL вважається більшим за всі значення — в кінці при ASC і на початку при DESC. У MySQL навпаки. Явно: NULLS LAST.

-- 10 останніх транзакцій; id як другий ключ робить порядок стабільним
SELECT * FROM transactions
ORDER BY created_at DESC, id DESC
LIMIT 10;