Типові помилки при створенні та зміні таблиць

Привіт, майбутні гуру PostgreSQL! Сьогоднішня тема присвячена, мабуть, одному з найцінніших скілів у програмуванні — уникненню помилок. Від усіх, звісно, не втечеш, особливо якщо ти тільки починаєш вивчати SQL. Але швидко розібратися з типовими помилками — цілком реально. Це як пройтися в темряві по кімнаті з купою кутів: пару разів вдарився, зате потім знаєш, де що стоїть. А я допоможу обійти "гострі кути" при створенні та зміні таблиць.

Помилка 1: Неправильний вибір типу даних

Робота з типами даних — як підбір ключа до замка. Неправильний "ключ" у вигляді типу даних може призвести до того, що таблиця буде працювати некоректно або стане менш ефективною.

Приклад помилки:

Ти хочеш створити колонку для зберігання телефонних номерів і по звичці вибираєш тип INTEGER. Звучить логічно, бо номери — це ж числа. Але біда в тому, що INTEGER не підходить для даних, які:

• Починаються з нуля (0123456789 стане просто 123456789).
• Містять символи, такі як "+" або пробіли.

-- Неправильно:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Ой-ой
);

-- Правильно:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Підходить для зберігання всіх форматів номерів
);

Як уникнути?
Уважно аналізуй природу даних, які будеш зберігати, перед вибором типу даних. Якщо сумніваєшся, зазирни в офіційну документацію PostgreSQL про типи даних.

Помилка 2: Ігнорування обмежень NOT NULL, CHECK, UNIQUE

Обмеження допомагають підтримувати цілісність даних. Забудеш про них — і в твоїй таблиці почнеться хаос типу наявності порожніх значень там, де їх бути не повинно.

Приклад помилки: Ти створюєш таблицю для зберігання студентів і забуваєш про те, що ім'я та вік студента обов'язкові.

-- Неправильно:
CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER
);

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Ой, що це?!

Правильний варіант:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Ім'я обов'язкове
    age INTEGER CHECK (age > 0) -- Вік має бути додатнім
);

Як уникнути?
Завжди задавай обмеження для обов'язкових полів. Це свого роду "захисний механізм", який не дає потрапити проблемним даним.

Помилка 3: Проблеми з унікальністю

Іноді ти можеш забути додати обмеження унікальності UNIQUE на колонку, яка має містити унікальні значення. Це призводить до дублювання даних.

Приклад помилки: Ти створюєш таблицю для зберігання email-адрес, але забуваєш додати UNIQUE.

-- Неправильно:
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100)
);

INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO users (email) VALUES ('user@example.com'); -- Вже є такий email!

Правильний варіант:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Унікальні email
);

Як уникнути?
Завжди додавай UNIQUE, якщо значення мають бути унікальними. Якщо хочеш гнучкості, можна використати CONSTRAINT з іменем, щоб ідентифікувати обмеження:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100),
    CONSTRAINT unique_email UNIQUE (email)
);

Помилка 4: Помилка при зміні таблиць (ALTER TABLE)

Використання ALTER TABLE може бути підступним, особливо якщо дані вже є в таблиці. Наприклад, ти можеш забути про допустимі значення в колонці, що призведе до помилок при роботі з існуючими даними.

Приклад помилки: Ти хочеш додати обмеження NOT NULL на вже існуючу колонку, але в стовпці є значення NULL.

-- Неправильно:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Помилка!

Якщо в таблиці вже є рядки з NULL, PostgreSQL не дозволить тобі додати обмеження.

Що робити?

Перед додаванням обмежень переконайся, що дані відповідають вимогам. Наприклад:

UPDATE students SET name = 'Nevidomyi' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;

Помилка 5: Видалення таблиць або даних без перевірки

Видалення таблиці за допомогою DROP TABLE або даних через DELETE — це дія, яку не можна відкотити. Тому перед видаленням завжди перевіряй, що саме видаляєш.

Приклад помилки:

DROP TABLE courses; -- Ой, це була не та таблиця!

Як уникнути?

Використовуй команду \dt у psql, щоб подивитися, які таблиці існують, і переконайся, що видаляєш потрібну.

Або використовуй DROP TABLE IF EXISTS, щоб уникнути помилок при спробі видалити неіснуючу таблицю:

DROP TABLE IF EXISTS courses;

Помилка 6: Проблеми з тимчасовими таблицями

Тимчасові таблиці зникають наприкінці сесії. Якщо ти випадково спробуєш використати тимчасову таблицю, а сесія вже завершилась, отримаєш помилку.

Приклад помилки:

CREATE TEMP TABLE temp_students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

-- Завершили сесію, а тепер...
SELECT * FROM temp_students; -- Помилка: таблиці більше нема!

Як уникнути?

Зберігай тимчасові дані, які треба використовувати між сесіями, у звичайних таблицях або документуй їх використання в межах однієї сесії.

Помилка 7: Забув про обмеження під час тестування

Часто під час розробки ти можеш пропустити деякі обмеження, думаючи, що "ну, потім додамо". Але, як показує практика, "потім" може забутися.

Приклад помилки:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- Вставляємо дані:
INSERT INTO test_table (name) VALUES ('Dublikatna nazva');
INSERT INTO test_table (name) VALUES ('Dublikatna nazva'); -- Проблеми починаються...

Як уникнути?

Одразу створюй таблиці з обмеженнями, навіть на етапі тестування:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Збавить від головного болю
);