Пошук уроків, статей та іншого контенту
Чому дані організовують таблицями з жорсткою схемою, а не просто зберігають як файли JSON.
Зберігати дані застосунку просто у файлах (JSON, текстові файли) працює для дуже маленьких обсягів, але швидко ламається на практиці: два процеси, що одночасно записують у той самий файл, можуть пошкодити дані; пошук конкретного запису в мегабайтах JSON вимагає прочитати весь файл; немає способу гарантувати, що пов'язані дані (замовлення й товар, на який воно посилається) лишаються узгодженими між собою.
Реляційна база даних організовує дані в таблиці (рядки й стовпці, схоже на аркуш електронної таблиці) з жорстко визначеною схемою — заздалегідь описано, які стовпці існують і якого вони типу. Таблиці пов'язуються між собою через зовнішні ключі (детально в уроці про Constraints) — замовлення посилається на конкретного користувача не копіюванням його даних, а посиланням на його рядок в іншій таблиці.
-- Дві пов'язані таблиці замість дублювання даних користувача в кожному замовленні
users: id | name | email
orders: id | user_id | totalСистеми керування реляційними базами даних (PostgreSQL, MySQL) гарантують властивості, об'єднані абревіатурою ACID: Atomicity (операція виконується повністю або не виконується взагалі — детально в уроці про транзакції), Consistency (дані завжди відповідають заданим правилам цілісності), Isolation (паралельні операції не заважають одна одній непередбачувано), Durability (підтверджені зміни не втрачаються навіть при збої сервера одразу після підтвердження).
Відкритий код, безкоштовний — без ліцензійних обмежень для продакшн-використання.
Суворо дотримується стандарту SQL і має репутацію особливо надійної, коректної реалізації ACID-гарантій.
Розширюваний: підтримує складні типи даних (JSONB, масиви, geo-дані через розширення) понад базовий реляційний набір.
Великий набір вбудованих інструментів аналізу продуктивності запитів (детально в уроці про EXPLAIN).
У цьому проєкті доступ до PostgreSQL відбувається не через сирі SQL-запити напряму, а через Prisma ORM (згадується в CLAUDE.md проєкту) — ORM генерує SQL за вас на основі декларативної схеми. Розуміння самого SQL і реляційної моделі однаково критичне: ORM приховує синтаксис, але не приховує наслідки поганих запитів (стаття «N+1 Query Problem») чи відсутніх індексів (стаття «Індекси в PostgreSQL»).
Зберігати структуровані, пов'язані дані у файлах чи одному величезному JSON-документі там, де реляційна модель із самого початку підходить краще — втрачаються ACID-гарантії й можливість ефективно запитувати частину даних.
Вважати SQL «застарілою» технологією, яку повністю замінює ORM, — ORM генерує SQL, а не скасовує потребу розуміти, що саме цей SQL робить і скільки коштує.
Плутати реляційну базу даних із конкретною СУБД — PostgreSQL, MySQL, SQLite всі реалізують реляційну модель, але з різними компромісами й розширеннями.
Реляційна база даних організовує дані в таблиці з жорсткою схемою й зв'язками через зовнішні ключі, а СУБД (PostgreSQL) гарантує ACID-властивості — атомарність, узгодженість, ізоляцію, довговічність — яких важко досягти, зберігаючи дані у звичайних файлах вручну. PostgreSQL — відкрита, суворо стандартна й розширювана реалізація цієї моделі, широко використовувана і в цьому проєкті через Prisma ORM.