Пошук уроків, статей та іншого контенту
CREATE TABLE, первинний ключ та практичні конвенції іменування стовпців і таблиць.
Таблиця створюється командою CREATE TABLE зі списком стовпців, кожен із заданим типом даних (детально в наступному уроці) і, за потреби, додатковими правилами:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
email TEXT NOT NULL UNIQUE,
created_at TIMESTAMP NOT NULL DEFAULT now()
);Первинний ключ — стовпець (чи набір стовпців), що однозначно ідентифікує кожен рядок таблиці; PostgreSQL автоматично створює для нього унікальний індекс (стаття «Індекси в PostgreSQL»). SERIAL — зручний тип, що автоматично генерує послідовне ціле число для кожного нового рядка; для нових проєктів часто обирають UUID замість послідовного числа — непередбачуваний ззовні ідентифікатор (наприклад, щоб URL /users/1, /users/2 не розкривали кількість користувачів у системі).
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT NOT NULL
);snake_case для назв таблиць і стовпців (created_at, а не createdAt) — історична конвенція SQL і PostgreSQL, на відміну від camelCase у самому JavaScript/TypeScript-коді.
Назва таблиці в множині (users, а не user) — поширена, хоч і не універсальна конвенція; головне — узгодженість у межах одного проєкту.
Зовнішній ключ, що посилається на іншу таблицю, зазвичай називають за шаблоном <таблиця_в_однині>_id (user_id, а не userId чи uid).
Схема не є незмінною — ALTER TABLE додає, видаляє чи змінює стовпці вже існуючої таблиці. У реальних проєктах такі зміни зазвичай не пишуть вручну одноразовими командами, а оформлюють як міграції — послідовні, версійовані файли змін схеми, які застосовує інструмент на кшталт Prisma Migrate, щоб схема бази даних узгоджено еволюціонувала разом із кодом застосунку в усіх середовищах.
ALTER TABLE users ADD COLUMN phone TEXT;ALTER TABLE на великій таблиці в продакшені може бути небезпечним — деякі зміни (додавання стовпця з NOT NULL без значення за замовчуванням, зміна типу стовпця) вимагають блокування таблиці на час операції, що зупиняє інші запити до неї. Продакшн-міграції великих таблиць зазвичай плануються обережно, окремо від звичайної розробки.
Забути NOT NULL там, де поле логічно завжди має бути заповненим, — база даних мовчки дозволяє NULL, і код застосунку потім змушений усюди перевіряти цей випадок вручну.
Змішувати camelCase і snake_case у назвах стовпців у межах однієї бази даних — ускладнює читання й може вимагати додаткового мапінгу на рівні ORM.
Виконувати ALTER TABLE вручну напряму в продакшн-базі даних замість керованої системи міграцій — втрачається версіонована, відтворювана історія змін схеми.
CREATE TABLE визначає структуру даних — стовпці, їхні типи, первинний ключ. SERIAL чи UUID — два типові підходи до генерації первинного ключа, кожен зі своїми компромісами (передбачуваність послідовного номера проти непередбачуваності UUID). Зміни вже існуючої схеми (ALTER TABLE) у реальних проєктах оформлюють як версійовані міграції, а не одноразові ручні команди в продакшн-базі даних.