SQL для Junior: питання на співбесіду

3 питання рівня Junior з теми SQL з розгорнутими відповідями, порадами та перевіркою.

Питання Флеш-картки Тест3

Тема

Усі18 Core PHP6 Laravel4 Symfony1 WordPress2 SQL3 DevOps1 Yii1 Архітектура0

Рівень

Усі Junior3 Middle5 Senior3

3 питання

SQL

Чим HAVING відрізняється від WHERE і як працює GROUP BY? ЧАСТО ПИТАЮТЬ

SQL·Junior ·GROUP BY ·HAVING ·агрегати

WHERE фільтрує рядки до групування й не бачить агрегатів, GROUP BY згортає рядки в групи, HAVING фільтрує вже готові групи за значенням агрегату.

Як питають

Чому запит із WHERE COUNT(*) > 3 падає з помилкою?

У якому порядку база виконує WHERE, GROUP BY і HAVING?

Чи можна писати HAVING без GROUP BY і що тоді буде?

Чому MySQL лається на колонку, якої немає в GROUP BY?

Пояснення

Щоб зрозуміти різницю, треба тримати в голові логічний порядок виконання запиту: FROM і JOIN збирають рядки, WHERE фільтрує їх по одному, GROUP BY згортає рядки в групи за однаковими значеннями ключа групування, всередині груп обчислюються агрегати (COUNT, SUM, AVG, MIN, MAX), HAVING відкидає непотрібні групи, і тільки потім працюють SELECT, ORDER BY та LIMIT. Це не порядок написання, а порядок сенсу — фізично планувальник може робити по-своєму, але результат зобовʼязаний збігатися з цією моделлю.

Звідси головна відповідь: WHERE не бачить COUNT(*), бо на момент його роботи груп ще не існує — є лише окремі рядки, і запит WHERE COUNT(*) >= 3 падає з помилкою (Invalid use of group function у MySQL, aggregate functions are not allowed in WHERE у PostgreSQL). HAVING, навпаки, виконується після агрегації, тому оперує вже порахованими значеннями. Симетрично HAVING майже не має сенсу для звичайної колонки: після групування окремих рядків уже немає, є ключ групування й агрегати.

Другий бік — продуктивність. Технічно можна винести умову на звичайну колонку в HAVING (MySQL це проковтне, бо дозволяє в HAVING посилатися на колонки й аліаси SELECT; PostgreSQL стандартно вимагатиме агрегат або колонку з GROUP BY). Але тоді база згрупує зайві рядки й лише потім їх викине, а індекс по цій колонці не спрацює для звуження пошуку. Правило просте: умова про значення рядка — у WHERE, умова про результат агрегації — у HAVING.

Після GROUP BY у SELECT дозволені тільки колонки з ключа групування та агрегати. MySQL до 5.7.5 із вимкненим ONLY_FULL_GROUP_BY мовчки повертав довільне значення з групи, і це давало нестабільні результати між запусками; з 5.7.5 режим увімкнений за замовчуванням, а PostgreSQL поводився так завжди. Виняток — функційна залежність: якщо групувати за первинним ключем (GROUP BY u.id), інші колонки цієї таблиці брати можна, бо вони визначені однозначно (PostgreSQL з 9.1, MySQL 8).

Дві деталі, на яких найчастіше помиляються джуни. Перша: COUNT(*) рахує рядки групи, а COUNT(column), SUM, AVG ігнорують NULL — тому COUNT(o.coupon) менший за COUNT(*), і це не баг. Друга: GROUP BY не гарантує сортування. У старих MySQL воно було побічним ефектом реалізації, у 8.0 неявне сортування й модифікатори ASC/DESC для GROUP BY прибрані, тож потрібний порядок задають явним ORDER BY.

КодSQL

-- Питання: користувачі, у яких від 3 оплачених замовлень за 2026 рік,
-- на суму понад 10000, найбільші зверху.
SELECT
    u.id,
    u.email,
    COUNT(*)        AS paid_orders,   -- рядків у групі
    SUM(o.total)    AS revenue,       -- SUM ігнорує NULL
    COUNT(o.coupon) AS with_coupon    -- рахує лише не-NULL купони
FROM users u
JOIN orders o ON o.user_id = u.id
-- WHERE працює до групування: відсікає рядки, може використати індекс
WHERE o.status = 'paid'
  AND o.created_at >= '2026-01-01'
-- GROUP BY згортає рядки в групи; u.email можна брати,
-- бо u.id — первинний ключ (функційна залежність)
GROUP BY u.id, u.email
-- HAVING працює після агрегації: тут і тільки тут доступні COUNT/SUM
HAVING COUNT(*) >= 3 AND SUM(o.total) > 10000
-- GROUP BY не сортує сам: у MySQL 8.0 неявне сортування прибрано
ORDER BY revenue DESC
LIMIT 20;

-- Помилка: агрегата у WHENE ще не існує, груп немає
-- WHERE COUNT(*) >= 3        -- ERROR: Invalid use of group function / aggregate not allowed

-- Кілька лічильників за один прохід (PostgreSQL)
SELECT user_id,
       COUNT(*)                                   AS all_orders,
       COUNT(*) FILTER (WHERE status = 'paid')    AS paid_orders
FROM orders
GROUP BY user_id;

Що хоче почути інтервʼюер

Логічний порядок виконання: FROM/JOIN → WHERE → GROUP BY → агрегати → HAVING → SELECT → ORDER BY → LIMIT; звідси все інше випливає.

Що WHERE не бачить COUNT/SUM, бо на момент його роботи груп ще немає, а HAVING бачить, бо працює вже після агрегації.

Що умову на звичайну колонку треба ставити у WHERE, а не в HAVING: менше рядків для групування і доступний індекс.

Що після GROUP BY у SELECT можна брати лише колонки з GROUP BY або агрегати — ONLY_FULL_GROUP_BY у MySQL з 5.7.5 увімкнено за замовчуванням.

Що COUNT(*) рахує рядки, а COUNT(col) і SUM/AVG ігнорують NULL — це різні числа.

Типові помилки

Писати WHERE COUNT(*) > 3 — синтаксична помилка, агрегат у WHERE неможливий.

Переносити всі умови в HAVING «щоб працювало»: запит дає правильний результат, але групує зайві рядки й не використовує індекс.

Плутати «фільтр до групування» і «фільтр після»: WHERE status = 'paid' і HAVING SUM(...) > 0 дають різні відповіді на різні питання.

Вважати, що GROUP BY сам сортує результат: у MySQL 8.0 неявне сортування прибрано, без ORDER BY порядок не визначений.

Використовувати COUNT(column) там, де треба порахувати всі рядки групи, і дивуватися меншому числу через NULL.

ПОРАДА

Скажіть одним реченням: «WHERE — про рядки, HAVING — про групи», і одразу назвіть порядок виконання. Далі додайте, що умову на звичайну колонку завжди тримають у WHERE, бо це менше роботи для GROUP BY.

Додаткові питанняЗ ВІДПОВІДЯМИ

Так. Без GROUP BY весь результат — це одна група, тому `SELECT COUNT(*) FROM orders HAVING COUNT(*) > 100` поверне один рядок, якщо замовлень більше ста, і жодного, якщо менше. На практиці так пишуть рідко; корисніше це як ілюстрація того, що HAVING завжди працює над групами, просто інколи група одна.

До MySQL 5.7.5 режим ONLY_FULL_GROUP_BY був вимкнений і база мовчки брала довільне значення з групи — звідси нестабільні результати. З 5.7.5 він увімкнений за замовчуванням і такий запит падає з помилкою, як у PostgreSQL. Виняток в обох базах — функційна залежність: якщо групувати за первинним ключем таблиці (`GROUP BY u.id`), решту колонок цієї таблиці брати можна, бо вони однозначно визначені ключем. Це вміє PostgreSQL з 9.1 і MySQL 8. Обхід через `ANY_VALUE()` у MySQL є, але це визнання, що запит неточний.

У WHERE. WHERE відсіє неоплачені рядки до групування, тож GROUP BY отримає менший набір, а індекс по `status` або складений індекс може взагалі спрацювати. Той самий фільтр у HAVING неможливий для звичайної колонки (її вже немає після агрегації) або дасть інший результат, якщо загорнути його в агрегат. Правило: умова на значення рядка — WHERE, умова на результат COUNT/SUM/AVG — HAVING.

Умовним агрегатом. У PostgreSQL це стандартний `COUNT(*) FILTER (WHERE status = 'paid')`, у MySQL — `SUM(status = 'paid')` або сумісний з обома `COUNT(CASE WHEN status = 'paid' THEN 1 END)`: CASE повертає NULL для решти рядків, а COUNT ігнорує NULL. Так один прохід по таблиці дає кілька різних лічильників без підзапитів і JOIN-ів.

Сторінка питання →

SQL

Чим відрізняються INNER JOIN і LEFT JOIN? ЧАСТО ПИТАЮТЬ

SQL·Junior ·JOIN ·SQL

INNER JOIN лишає лише ті рядки, для яких знайшлася пара в обох таблицях; LEFT JOIN лишає всі рядки лівої таблиці, підставляючи NULL там, де пари немає.

Як питають

Чому LEFT JOIN повернув менше рядків, ніж очікувалось?

Як знайти користувачів без жодного замовлення?

У чому різниця між умовою в ON і в WHERE?

Пояснення

INNER JOIN повертає лише ті рядки, для яких умова звʼязку знайшла пару в обох таблицях: користувачі без замовлень у результат не потрапляють. LEFT JOIN бере всі рядки лівої таблиці й додає до них збіги з правої; якщо збігу немає, колонки правої таблиці заповнюються NULL. RIGHT JOIN є дзеркалом LEFT, а FULL OUTER JOIN обʼєднує обидва й у MySQL відсутній.

Найважливіше для практики — різниця між умовою в ON і у WHERE. ON описує, як шукати пару, і при LEFT JOIN відсутність пари дає NULL. WHERE застосовується вже до зібраного результату, і порівняння NULL з чим завгодно не є true, тому рядки без пари зникають. Так LEFT JOIN orders o ... WHERE o.status = 'paid' непомітно стає INNER JOIN. Якщо потрібні всі користувачі, а замовлення лише оплачені, умова на статус іде в ON.

Цей самий NULL є інструментом: WHERE o.id IS NULL після LEFT JOIN знаходить рядки без відповідника, і це стандартний anti-join поруч із NOT EXISTS. NOT IN з підзапитом, який може повернути NULL, дає порожній результат, тому в таких запитах його уникають.

Окрема пастка — множення рядків. JOIN один-до-багатьох повертає по рядку на кожен збіг, тому агрегати після нього подвоюються. Агрегувати праву таблицю варто до JOIN, у підзапиті або CTE.

КодSQL

-- INNER: лише користувачі, у яких є замовлення
SELECT u.id, o.id AS order_id
FROM users u
INNER JOIN orders o ON o.user_id = u.id;

-- LEFT: усі користувачі; без замовлень order_id буде NULL
SELECT u.id, o.id AS order_id
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

-- Пастка: умова у WHERE відкидає NULL-рядки, це вже фактично INNER JOIN
SELECT u.id, o.id
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid';

-- Правильно: умова на праву таблицю в ON, користувачі без оплат лишаються
SELECT u.id, o.id
FROM users u
LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid';

-- Користувачі без жодного замовлення
SELECT u.id
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL;

-- Те саме без JOIN, безпечно до NULL
SELECT u.id FROM users u
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);

Що хоче почути інтервʼюер

Чітке визначення обох через результат: INNER це перетин, LEFT це вся ліва таблиця плюс збіги з правої або NULL.

Що умова на праву таблицю у WHERE відфільтровує NULL-рядки й перетворює LEFT JOIN на INNER, а в ON вона обмежує лише збіг.

Що IS NULL по колонці правої таблиці після LEFT JOIN є стандартним способом знайти рядки без відповідника, як і NOT EXISTS.

Що JOIN на звʼязок один-до-багатьох множить рядки, тому COUNT і SUM після нього потребують DISTINCT або підзапиту.

Що RIGHT JOIN це дзеркало LEFT, а FULL OUTER JOIN є у PostgreSQL і відсутній у MySQL.

Типові помилки

Казати, що різниця лише у швидкості.

Писати умову на праву таблицю у WHERE й отримувати INNER JOIN, не розуміючи чому.

Рахувати COUNT(*) після JOIN один-до-багатьох і отримувати кількість замовлень замість кількості користувачів.

Використовувати NOT IN з підзапитом, який може повернути NULL: результат порожній, бо порівняння з NULL не є true.

Не знати, що для LEFT JOIN потрібен індекс на колонці звʼязку правої таблиці, інакше кожен рядок лівої сканує праву.

ПОРАДА

Саме приклад із WHERE проти ON відрізняє того, хто розуміє JOIN, від того, хто вивчив визначення. Намалюйте два кола або наведіть таблицю з трьома рядками.

Додаткові питанняЗ ВІДПОВІДЯМИ

LEFT JOIN спершу будує результат: для користувачів без замовлень усі колонки orders дорівнюють NULL. Потім WHERE o.status = 'paid' перевіряє NULL = 'paid', що не є true, і такі рядки відкидаються. Лишаються лише користувачі зі збігом, тобто те саме, що INNER JOIN. Умова в ON застосовується під час пошуку пари, тому користувач без оплачених замовлень лишається з NULL.

LEFT JOIN orders o ON o.user_id = u.id WHERE o.id IS NULL, або NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id). NOT EXISTS часто читається краще й безпечний до NULL, на відміну від NOT IN. Оптимізатори PostgreSQL і MySQL 8 виконують обидва варіанти як anti-join, тому продуктивність зазвичай однакова.

JOIN один-до-багатьох повертає по рядку на кожен збіг: користувач з трьома замовленнями зʼявиться тричі. SUM(u.balance) додасть баланс тричі. Рішення: агрегувати праву таблицю в підзапиті чи CTE до JOIN, або рахувати COUNT(DISTINCT u.id). Це найчастіша помилка у звітах.

Декартів добуток: кожен рядок лівої таблиці з кожним рядком правої, без умови. Потрібен для генерації комбінацій, наприклад сітка дат і категорій для звіту з нулями, або для JOIN з таблицею з одним рядком параметрів. Випадковий CROSS JOIN через забуту умову дає мільйони рядків.

Сторінка питання →

SQL

Як NULL поводиться в порівняннях, агрегатах і унікальних індексах? ЧАСТО ПИТАЮТЬ

SQL·Junior ·тризначна логіка ·UNIQUE ·агрегати

NULL — це «невідомо», а не значення: будь-яке порівняння з ним дає UNKNOWN і рядок не проходить WHERE, агрегати мовчки пропускають NULL замість того щоб рахувати їх нулями, а UNIQUE вважає різні NULL різними, тому дублікати проходять.

Як питають

Чому `WHERE bonus = NULL` не повертає жодного рядка?

Чому після додавання умови `status <> 'paid'` зі звіту зникли рядки, у яких статус узагалі не заповнений?

Скільки рядків з однаковим NULL можна вставити в колонку з UNIQUE індексом?

Чому AVG по колонці дає більше число, ніж очікує бухгалтерія?

Пояснення

NULL у SQL означає не «порожньо» і не «нуль», а «значення невідоме». Через це логіка стає тризначною: вираз може бути TRUE, FALSE або UNKNOWN. bonus = NULL — це питання «чи дорівнює невідоме число тисячі», відповідь на яке невідома, тому результат UNKNOWN. WHERE пропускає далі лише рядки з TRUE, тож і = NULL, і <> NULL завжди дають порожній результат — без помилки й без попередження. Заперечення теж не допомагає: NOT UNKNOWN — це знову UNKNOWN. Саме звідси найпоширеніший баг у звітах: після додавання умови status <> 'paid' із вибірки тихо зникають усі рядки, де status взагалі не заповнений. Перевіряти наявність значення можна лише через IS NULL та IS NOT NULL, а порівнювати дві потенційно порожні колонки — через IS NOT DISTINCT FROM у PostgreSQL або <=> у MySQL.

Той самий механізм ламає NOT IN з підзапитом. Якщо підзапит повернув хоч один NULL, вираз id NOT IN (1, NULL) розкладається в id <> 1 AND id <> NULL, друга частина назавжди UNKNOWN, і результат ніколи не стане TRUE. Запит повертає нуль рядків, хоча дані на місці. Безпечна заміна — NOT EXISTS, який працює через звичайне зіставлення рядків і на NULL не спотикається; альтернатива — прибрати NULL прямо в підзапиті через WHERE col IS NOT NULL. Це одна з тих помилок, які проходять код-рев'ю і виявляються вже на проді, бо запит синтаксично коректний.

В агрегатах правило інше: SUM, AVG, MIN, MAX і COUNT(col) просто пропускають NULL, а не підставляють нуль. Тому COUNT(*) рахує рядки, COUNT(bonus) — лише заповнені бонуси, а AVG(bonus) ділить суму на кількість непорожніх значень. Для трьох співробітників із бонусами 1000, NULL і 0 середнє буде 500, а не 333.33 — і саме тут звіт розходиться з очікуваннями бізнесу. Якщо порожнє значення за змістом дорівнює нулю, це треба сказати явно: AVG(COALESCE(bonus, 0)). Окремо варто памʼятати, що SUM по порожній вибірці повертає NULL, а не 0, тому в коді така сума теж потребує COALESCE.

А от GROUP BY, DISTINCT, UNION і віконні PARTITION BY користуються третім правилом: там усі NULL вважаються однаковими й потрапляють в одну групу. Виходить, що в одному запиті NULL може бути одночасно «не рівним самому собі» у WHERE і «рівним самому собі» у GROUP BY. Унікальний індекс належить до першої категорії: NULL для нього різні, тому UNIQUE (email) спокійно пропускає скільки завгодно рядків із порожнім email — і в MySQL, і в PostgreSQL (для контрасту, SQL Server дозволяє лише один NULL). З PostgreSQL 15 зʼявився явний перемикач UNIQUE NULLS NOT DISTINCT; у MySQL 8.4 такого немає, там або NOT NULL, або перевірка на рівні застосунку, або згенерована колонка з підстановкою.

Практичний висновок: NOT NULL має бути станом за замовчуванням, а nullable-колонка — свідомим рішенням для випадків, де «невідомо» справді окремий стан (deleted_at, closed_at). Для сум і лічильників краще NOT NULL DEFAULT 0, бо будь-яка арифметика з NULL дає NULL і помилка розповзається далі по обчисленнях. Компроміс у зворотний бік теж є: заміна NULL на «магічні» значення на кшталт 0, порожнього рядка чи '1970-01-01' робить дані брехливими та псує агрегати, тож замінювати NULL заглушками лише щоб уникнути IS NULL — гірше, ніж навчитися з ним працювати.

КодSQL

-- Дані: employees
-- id | name  | manager_id | bonus | email
--  1 | Оля   |       NULL |  1000 | [email protected]
--  2 | Іван  |          1 |  NULL | NULL
--  3 | Петро |       NULL |     0 | NULL

-- 1. Порівняння з NULL дає UNKNOWN, а WHERE пропускає лише TRUE
SELECT * FROM employees WHERE bonus = NULL;   -- 0 рядків завжди
SELECT * FROM employees WHERE bonus IS NULL;  -- Іван

-- 2. Заперечення не рятує: NOT(UNKNOWN) теж UNKNOWN
SELECT count(*) FROM employees WHERE bonus <> 1000;  -- 1 (Петро), Іван мовчки зник

-- 3. NOT IN по nullable-колонці не поверне нічого
SELECT * FROM employees WHERE id NOT IN (SELECT manager_id FROM employees);  -- 0 рядків
-- Правильно: NOT EXISTS коректно працює з NULL
SELECT e.* FROM employees e
WHERE NOT EXISTS (SELECT 1 FROM employees m WHERE m.manager_id = e.id);

-- 4. Агрегати пропускають NULL, а не рахують його за 0
SELECT count(*)     AS rows_total,  -- 3
       count(bonus) AS with_bonus,  -- 2
       sum(bonus)   AS total,       -- 1000
       avg(bonus)   AS avg_bonus    -- 500, а не 333.33
FROM employees;

-- 5. GROUP BY і DISTINCT, навпаки, збирають усі NULL в одну групу
SELECT bonus, count(*) FROM employees GROUP BY bonus;  -- є рядок bonus = NULL

-- 6. UNIQUE вважає NULL різними: обидва рядки з email = NULL пройдуть
CREATE UNIQUE INDEX employees_email_uniq ON employees (email);
-- PostgreSQL 15+: заборонити повтори NULL явно
CREATE UNIQUE INDEX employees_email_strict ON employees (email) NULLS NOT DISTINCT;

Що хоче почути інтервʼюер

Що SQL має тризначну логіку: TRUE, FALSE, UNKNOWN, і WHERE пропускає лише TRUE, тому і `= NULL`, і `<> NULL` дають порожній результат.

Що перевіряти треба через `IS NULL` / `IS NOT NULL`, а для порівняння двох значень, з яких обидва можуть бути NULL, є `IS NOT DISTINCT FROM` у PostgreSQL і оператор `<=>` у MySQL.

Що `COUNT(*)` рахує рядки, а `COUNT(col)`, `SUM`, `AVG` пропускають NULL: AVG ділить на кількість непорожніх значень, а не на кількість рядків.

Що GROUP BY і DISTINCT, навпаки, вважають усі NULL однією групою — це інше правило, ніж у порівняннях.

Що UNIQUE індекс у MySQL і PostgreSQL дозволяє скільки завгодно NULL, і що в PostgreSQL 15+ це вимикається через `UNIQUE NULLS NOT DISTINCT`.

Що `NOT IN` з підзапитом, який може повернути NULL, не поверне нічого, і замінюється на `NOT EXISTS`.

Типові помилки

Писати `WHERE deleted_at = NULL` або `WHERE deleted_at != NULL` замість `IS NULL` / `IS NOT NULL`.

Вважати, що умова `status <> 'paid'` включає рядки з NULL у status: вони мовчки випадають зі звіту.

Думати, що `SUM(bonus)` рахує NULL як 0, а `AVG(bonus)` ділить на загальну кількість рядків.

Розраховувати, що UNIQUE індекс на nullable-колонці не пустить два порожні значення — пустить, і в MySQL, і в PostgreSQL.

Використовувати `NOT IN (SELECT ...)` по nullable-колонці й дивуватись порожньому результату замість `NOT EXISTS`.

Плутати NULL з порожнім рядком `''` або з 0: у SQL це три різні значення (в Oracle порожній рядок і є NULL, у MySQL і PostgreSQL — ні).

ПОРАДА

Скажіть одним реченням: «NULL — це не значення, а відсутність знання, тому порівняння з ним дає не FALSE, а UNKNOWN». І одразу назвіть три різні правила: у WHERE усі NULL різні, у GROUP BY і DISTINCT — однакові, в агрегатах — просто пропускаються.

Додаткові питанняЗ ВІДПОВІДЯМИ

У PostgreSQL є стандартний оператор `a IS NOT DISTINCT FROM b`: він дає TRUE, коли обидва NULL, і FALSE, коли NULL лише з одного боку. У MySQL цього синтаксису немає, натомість є null-safe оператор `a <=> b` з такою ж семантикою. Портативний, але повільніший варіант — `a = b OR (a IS NULL AND b IS NULL)`; він гірший тим, що заважає планувальнику використати індекс. Такі порівняння часто потрібні в UPDATE-тригерах і в синхронізації даних, де треба зрозуміти, чи значення справді змінилось.

Бо підзапит повертає серед іншого NULL. `id NOT IN (1, NULL)` розкладається в `id <> 1 AND id <> NULL`; друга частина завжди UNKNOWN, тому весь вираз ніколи не буде TRUE — у кращому разі UNKNOWN. Результат: жодного рядка, і жодної помилки. Лікується або `NOT EXISTS (SELECT 1 FROM employees e WHERE e.manager_id = t.id)`, який коректно працює з NULL, або явним `WHERE manager_id IS NOT NULL` у підзапиті. `IN` цієї проблеми не має: там NULL просто не додає збігів.

Стандарт залишає це на розсуд СУБД. PostgreSQL вважає NULL найбільшим значенням: при `ASC` вони в кінці, при `DESC` — на початку; змінюється через `ORDER BY col ASC NULLS FIRST`. MySQL вважає NULL найменшим: при `ASC` вони перші, і `NULLS FIRST/LAST` там не підтримується — обходять через `ORDER BY col IS NULL, col`. Тому запит із сортуванням по nullable-колонці на MySQL і PostgreSQL дає різний порядок сторінок, і це реальний баг при міграції між базами.

CHECK пропускає рядок, коли умова дає UNKNOWN: `CHECK (price > 0)` не завадить вставити рядок із `price = NULL`. Щоб закрити цю дірку, потрібен окремий `NOT NULL` на колонці або `CHECK (price IS NOT NULL AND price > 0)`. Зовнішній ключ поводиться так само: nullable FK з NULL не перевіряється на існування батьківського рядка. Практичний висновок — `NOT NULL` за замовчуванням, а nullable робити свідомо, коли «невідомо» справді є окремим станом.

NULL доречний, коли «невідомо» або «незастосовно» — це справжній стан: дата видалення для не видаленого запису, дата закриття для відкритої задачі. Для лічильників і сум NULL зазвичай шкідливий: `NOT NULL DEFAULT 0` прибирає з коду нескінченні `COALESCE(amount, 0)` і робить арифметику передбачуваною, бо `NULL + 100` дорівнює NULL. Для тексту варто обрати щось одне — або NULL, або `''` — інакше в базі зʼявляться два різні «порожньо» і фільтр по одному з них половину рядків не побачить.

Сторінка питання →

Прогрес карток і тестів зберігається у профілі. Створити профіль·Увійти