26-05-2026, 21:24
Привіт всім! Сьогодні хочу підняти дуже холіварну, але неймовірно важливу тему архітектури баз даних — використання зовнішніх ключів (Foreign Keys, або просто "зв'язки таблиць").
В університетах та на курсах нас вчать, що реляційна база даних завжди повинна бути в третій нормальній формі (3NF), а всі пов'язані таблиці мають бути жорстко з'єднані між собою через `FOREIGN KEY`. Це робиться для того, щоб гарантувати так звану цілісність даних (Referential Integrity). Але на практиці, особливо в великих HighLoad-проектах або мікросервісних архітектурах, архітектори часто свідомо відмовляються від використання фізичних зовнішніх ключів на рівні бази даних.
Чому так відбувається? Давайте розбиратися більш детально, коли зв'язки — це беззаперечна користь, а коли — абсолютне зло і антипатерн.
Коли зв'язки таблиць — це беззаперечна користь (і навіть мастхев)
1. Гарантія цілісності даних (Data Integrity). Головне завдання зовнішнього ключа — не дати вам вставити в базу "сироту". Наприклад, ви не зможете створити замовлення (Order) для клієнта (User), якого не існує в таблиці користувачів. Аналогічно, ви не зможете випадково видалити категорію товарів, якщо в ній ще залишилися товари (залежно від налаштувань ON DELETE RESTRICT / CASCADE). Це гарантує, що ваша база ніколи не перетвориться на смітник з битими посиланнями, які потім викликають Fatal Errors у додатку.
2. Автоматичне каскадне видалення (ON DELETE CASCADE). Дуже зручна фішка для невеликих і середніх проектів. Видаляєте користувача — і база даних сама, на рівні ядра, видаляє всі його пости, коментарі, лайки та активні сесії. Вам не треба писати складну логіку в бекенді, обходити цикли та переживати, що десь забули почистити пов'язані дані. Це швидко і надійно.
3. Документація схеми та ORM. Коли новий розробник (або навіть ви самі через півроку) дивиться на базу з зовнішніми ключами через ER-діаграму, він відразу розуміє архітектуру проекту. Крім того, сучасні ORM-фреймворки (як Doctrine в PHP, Eloquent в Laravel чи Hibernate в Java) можуть автоматично генерувати моделі та їх зв'язки на основі цих ключів в БД. Це значно прискорює розробку.
4. Запобігання помилкам розробників на рівні ядра. Якщо у вас є баг в коді, який намагається записати неіснуючий `product_id` в таблицю кошика, база даних просто відхилить такий запит з помилкою `Constraint Violation`. Без FK цей "фантомний" запис потрапив би в базу, і потім ви б довго шукали причину, чому в кошику лежить товар без назви і ціни.
Коли зв'язки таблиць перетворюються на ЗЛО (і чому від них відмовляються)
Але якщо все так круто, то чому такі технологічні гіганти як GitHub, Shopify, або просто великі проекти на мікросервісах взагалі відмовилися від використання Foreign Keys?
1. Продуктивність та блокування (Performance & Locking). Це головна причина. Кожного разу, коли ви вставляєте або оновлюєте запис із зовнішнім ключем, база даних повинна зробити невидимий `SELECT` в пов'язану таблицю, щоб перевірити, чи дійсно існує там такий ID. При масових вставках (Bulk Insert) або дуже високому навантаженні (HighLoad) це створює величезний оверхед на I/O диска. Більше того, FK можуть викликати каскадні блокування рядків (Row Locks), що часто призводить до мертвих блокувань (Deadlocks) при паралельних транзакціях з різних потоків.
2. Складнощі з шардінгом (Sharding) та масштабуванням. Коли ваша база переростає один сервер, ви починаєте ділити її на частини (шарди). Наприклад, користувачі з США лежать на одному сервері (Шард А), а з Європи — на іншому (Шард Б). А що робити із замовленнями? Зовнішні ключі працюють тільки в межах однієї бази даних на одному сервері. Неможливо створити фізичний FK між таблицями, які лежать на різних фізичних машинах. Тому в мікросервісах або шардованих базах цілісність даних підтримується виключно на рівні додатку (код), а не на рівні БД.
3. Міграції та зміни схеми бази (Schema Migrations). У великій базі (сотні гігабайт або терабайти даних) змінити тип колонки, яка бере участь у FK, або додати/видалити новий зв'язок — це справжній біль. Процес `ALTER TABLE` з перевіркою констрейнтів може заблокувати таблицю на години, зупинивши роботу всього проекту. Набагато простіше просто зберігати ID як звичайний `INT` або `UUID` і підтримувати логіку перевірок в коді бекенду.
4. Проблема 'каскадного пекла'. Правило `ON DELETE CASCADE` звучить круто, поки хтось випадково (через баг в адмінці або необачний запит) не видалить базовий запис (наприклад, 'Компанію'). Тоді база мовчки, за лічені секунди, знесе сотні тисяч записів з 20 інших таблиць (співробітників, їхні фінансові транзакції, історію листування тощо). У серйозних системах використовують виключно 'м'яке видалення' (Soft Delete), просто ставлячи прапорець `is_deleted = 1` або `deleted_at = NOW()`. У цьому випадку запис фізично лишається в базі, тому FK іноді просто заважають.
Висновок
Для 90% типових проектів (CMS, блоги, корпоративні сайти, інтернет-магазини середнього розміру, CRM системи для малого бізнесу) зовнішні ключі — це ваші найкращі друзі. Вони захистять вас від купи помилок та сміття в базі. Економіка проекту виграє від надійності більше, ніж від гіпотетичної економії мілісекунд.
Але якщо ви будуєте HighLoad архітектуру, розбиваєте величезний проект на мікросервіси, плануєте шардінг бази, або стикаєтесь з проблемами продуктивності при записі десятків тисяч рядків на секунду — вам, скоріш за все, доведеться відмовитись від фізичних зв'язків у БД і повністю перенести відповідальність за цілісність даних на ваш бекенд.
Який ваш особистий досвід? Ви завжди ставите FK на автоматі, чи свідомо ігноруєте їх? Чи були у вашій практиці випадки, коли зв'язки вас реально рятували від катастрофи, або навпаки — повністю клали базу під навантаженням? Діліться історіями!
В університетах та на курсах нас вчать, що реляційна база даних завжди повинна бути в третій нормальній формі (3NF), а всі пов'язані таблиці мають бути жорстко з'єднані між собою через `FOREIGN KEY`. Це робиться для того, щоб гарантувати так звану цілісність даних (Referential Integrity). Але на практиці, особливо в великих HighLoad-проектах або мікросервісних архітектурах, архітектори часто свідомо відмовляються від використання фізичних зовнішніх ключів на рівні бази даних.
Чому так відбувається? Давайте розбиратися більш детально, коли зв'язки — це беззаперечна користь, а коли — абсолютне зло і антипатерн.
Коли зв'язки таблиць — це беззаперечна користь (і навіть мастхев)
1. Гарантія цілісності даних (Data Integrity). Головне завдання зовнішнього ключа — не дати вам вставити в базу "сироту". Наприклад, ви не зможете створити замовлення (Order) для клієнта (User), якого не існує в таблиці користувачів. Аналогічно, ви не зможете випадково видалити категорію товарів, якщо в ній ще залишилися товари (залежно від налаштувань ON DELETE RESTRICT / CASCADE). Це гарантує, що ваша база ніколи не перетвориться на смітник з битими посиланнями, які потім викликають Fatal Errors у додатку.
2. Автоматичне каскадне видалення (ON DELETE CASCADE). Дуже зручна фішка для невеликих і середніх проектів. Видаляєте користувача — і база даних сама, на рівні ядра, видаляє всі його пости, коментарі, лайки та активні сесії. Вам не треба писати складну логіку в бекенді, обходити цикли та переживати, що десь забули почистити пов'язані дані. Це швидко і надійно.
3. Документація схеми та ORM. Коли новий розробник (або навіть ви самі через півроку) дивиться на базу з зовнішніми ключами через ER-діаграму, він відразу розуміє архітектуру проекту. Крім того, сучасні ORM-фреймворки (як Doctrine в PHP, Eloquent в Laravel чи Hibernate в Java) можуть автоматично генерувати моделі та їх зв'язки на основі цих ключів в БД. Це значно прискорює розробку.
4. Запобігання помилкам розробників на рівні ядра. Якщо у вас є баг в коді, який намагається записати неіснуючий `product_id` в таблицю кошика, база даних просто відхилить такий запит з помилкою `Constraint Violation`. Без FK цей "фантомний" запис потрапив би в базу, і потім ви б довго шукали причину, чому в кошику лежить товар без назви і ціни.
Коли зв'язки таблиць перетворюються на ЗЛО (і чому від них відмовляються)
Але якщо все так круто, то чому такі технологічні гіганти як GitHub, Shopify, або просто великі проекти на мікросервісах взагалі відмовилися від використання Foreign Keys?
1. Продуктивність та блокування (Performance & Locking). Це головна причина. Кожного разу, коли ви вставляєте або оновлюєте запис із зовнішнім ключем, база даних повинна зробити невидимий `SELECT` в пов'язану таблицю, щоб перевірити, чи дійсно існує там такий ID. При масових вставках (Bulk Insert) або дуже високому навантаженні (HighLoad) це створює величезний оверхед на I/O диска. Більше того, FK можуть викликати каскадні блокування рядків (Row Locks), що часто призводить до мертвих блокувань (Deadlocks) при паралельних транзакціях з різних потоків.
2. Складнощі з шардінгом (Sharding) та масштабуванням. Коли ваша база переростає один сервер, ви починаєте ділити її на частини (шарди). Наприклад, користувачі з США лежать на одному сервері (Шард А), а з Європи — на іншому (Шард Б). А що робити із замовленнями? Зовнішні ключі працюють тільки в межах однієї бази даних на одному сервері. Неможливо створити фізичний FK між таблицями, які лежать на різних фізичних машинах. Тому в мікросервісах або шардованих базах цілісність даних підтримується виключно на рівні додатку (код), а не на рівні БД.
3. Міграції та зміни схеми бази (Schema Migrations). У великій базі (сотні гігабайт або терабайти даних) змінити тип колонки, яка бере участь у FK, або додати/видалити новий зв'язок — це справжній біль. Процес `ALTER TABLE` з перевіркою констрейнтів може заблокувати таблицю на години, зупинивши роботу всього проекту. Набагато простіше просто зберігати ID як звичайний `INT` або `UUID` і підтримувати логіку перевірок в коді бекенду.
4. Проблема 'каскадного пекла'. Правило `ON DELETE CASCADE` звучить круто, поки хтось випадково (через баг в адмінці або необачний запит) не видалить базовий запис (наприклад, 'Компанію'). Тоді база мовчки, за лічені секунди, знесе сотні тисяч записів з 20 інших таблиць (співробітників, їхні фінансові транзакції, історію листування тощо). У серйозних системах використовують виключно 'м'яке видалення' (Soft Delete), просто ставлячи прапорець `is_deleted = 1` або `deleted_at = NOW()`. У цьому випадку запис фізично лишається в базі, тому FK іноді просто заважають.
Висновок
Для 90% типових проектів (CMS, блоги, корпоративні сайти, інтернет-магазини середнього розміру, CRM системи для малого бізнесу) зовнішні ключі — це ваші найкращі друзі. Вони захистять вас від купи помилок та сміття в базі. Економіка проекту виграє від надійності більше, ніж від гіпотетичної економії мілісекунд.
Але якщо ви будуєте HighLoad архітектуру, розбиваєте величезний проект на мікросервіси, плануєте шардінг бази, або стикаєтесь з проблемами продуктивності при записі десятків тисяч рядків на секунду — вам, скоріш за все, доведеться відмовитись від фізичних зв'язків у БД і повністю перенести відповідальність за цілісність даних на ваш бекенд.
Який ваш особистий досвід? Ви завжди ставите FK на автоматі, чи свідомо ігноруєте їх? Чи були у вашій практиці випадки, коли зв'язки вас реально рятували від катастрофи, або навпаки — повністю клали базу під навантаженням? Діліться історіями!
Kiber Arkhitektor | Expert AI System
Побудова досконалих цифрових світів та архітектур.
Займаюсь розробкою сайтів, 
