Для чего нужен Primary Key?

Основная идея

Primary Key (первичный ключ) служит для уникальной идентификации каждой записи в таблице базы данных. Это фундаментальный механизм, обеспечивающий целостность данных и связи между таблицами.

Ключевые аспекты

Уникальная идентификация — каждая строка получает уникальный идентификатор
Связи между таблицами — Foreign Key ссылается на Primary Key другой таблицы
Целостность данных — гарантия отсутствия дубликатов и NULL значений
Производительность — автоматическое создание индекса ускоряет поиск
Ссылочная целостность — контроль связей при удалении/обновлении записей

Плюсы Primary Key

Быстрый поиск записей по ключу
Надёжная связь между таблицами
Защита от дублирования данных
Основа для построения отношений в БД

Минусы

Требует дополнительного места для хранения (особенно UUID)
При неправильном выборе ключа — проблемы с производительностью
Изменение Primary Key сложно после создания связей

Частые ошибки на собеседованиях

Не понимают связь между Primary Key и Foreign Key
Путают Primary Key с обычным UNIQUE constraint
Забывают, что Primary Key автоматически создаёт индекс
Не знают разницу между естественным и суррогатным ключом
Считают, что Primary Key обязательно должен быть числовым (может быть UUID, строка)

Введение и проблематика

В реляционных базах данных каждая таблица хранит множество записей. Как отличить одну запись от другой? Как связать данные из разных таблиц? Для решения этих задач используется Primary Key (первичный ключ).

Primary Key — это столбец (или набор столбцов), который уникально идентифицирует каждую строку в таблице. Значения Primary Key не могут повторяться и не могут быть NULL.

Зачем нужен Primary Key?

Уникальная идентификация — найти конкретную запись
Связи между таблицами — создание отношений через Foreign Key
Целостность данных — защита от дублирования
Оптимизация запросов — автоматический индекс

Базовая теория

Основные функции Primary Key

graph TD
    PK[Primary Key] --> ID[Уникальная идентификация]
    PK --> REL[Связи между таблицами]
    PK --> INT[Целостность данных]
    PK --> PERF[Производительность]
 
    REL --> FK[Foreign Key ссылается на PK]
    INT --> UNIQUE[Уникальность]
    INT --> NOTNULL[NOT NULL]
    PERF --> INDEX[Автоматический индекс]

Свойства Primary Key

Свойство	Описание
UNIQUE	Значения не могут повторяться
NOT NULL	Значения не могут быть пустыми
Неизменяемость	Рекомендуется не менять после создания
Минимальность	Использовать минимум столбцов

Практические примеры

1. Уникальная идентификация записей

Создание таблицы с Primary Key

sql

CREATE TABLE users (
    id SERIAL PRIMARY KEY,  -- Автоинкремент: 1, 2, 3...
    email VARCHAR(255) NOT NULL,
    name VARCHAR(100)
);

Вставка данных

sql

INSERT INTO users (email, name) VALUES
    ('john@example.com', 'John'),
    ('jane@example.com', 'Jane');
-- id автоматически: 1, 2

Поиск конкретной записи

sql

-- Быстрый поиск по Primary Key
SELECT * FROM users WHERE id = 1;

2. Связи между таблицами (Foreign Key)

Главная роль Primary Key — служить точкой связи для других таблиц.

erDiagram
    USERS ||--o{ ORDERS : "has many"
    USERS {
        int id PK
        string email
        string name
    }
    ORDERS {
        int id PK
        int user_id FK
        decimal total
        date created_at
    }

3. Защита целостности данных

sql

-- Попытка вставить дубликат Primary Key
INSERT INTO users (id, email, name) VALUES (1, 'new@example.com', 'New');
-- ERROR: duplicate key value violates unique constraint "users_pkey"
 
-- Попытка вставить NULL в Primary Key
INSERT INTO users (id, email, name) VALUES (NULL, 'null@example.com', 'Null');
-- ERROR: null value in column "id" violates not-null constraint

⚠️

Primary Key автоматически отклоняет дубликаты и NULL значения, защищая целостность данных.

Пограничные кейсы

Ссылочная целостность (Referential Integrity)

Primary Key работает совместно с Foreign Key для обеспечения ссылочной целостности:

sql

-- Создание связи с каскадным удалением
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    total DECIMAL(10, 2)
);
 
-- При удалении пользователя все его заказы удаляются автоматически
DELETE FROM users WHERE id = 1;  -- Удалит и все orders с user_id = 1

Варианты поведения при удалении

Опция	Поведение
`ON DELETE CASCADE`	Удалить связанные записи
`ON DELETE SET NULL`	Установить NULL в Foreign Key
`ON DELETE RESTRICT`	Запретить удаление (по умолчанию)
`ON DELETE SET DEFAULT`	Установить значение по умолчанию

Продвинутые аспекты

Выбор типа Primary Key

sql

-- Автоинкремент (PostgreSQL)
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255)
);
 
-- MySQL вариант
CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255)
);

Компактный размер (4 байта)
Быстрая сортировка и индексация
Предсказуемость (можно угадать следующий id)

Рекомендация: используйте суррогатные ключи (SERIAL или UUID). Естественные данные (email, номер паспорта) делайте UNIQUE, но не Primary Key.

Автоматический индекс

При создании Primary Key СУБД автоматически создаёт B-tree индекс:

sql

-- Проверка индексов в PostgreSQL
SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'users';
 
-- Результат: users_pkey - уникальный индекс на id

Это ускоряет:

SELECT ... WHERE id = ?
JOIN операции по Primary Key
Сортировку ORDER BY id

Плюсы и минусы

Аспект	Плюсы	Минусы
Идентификация	Чёткая уникальность	Требует планирования
Связи	Надёжные отношения	Каскадные операции могут быть опасны
Производительность	Автоматический индекс	Индекс занимает место
Целостность	Защита от дубликатов	Ограничивает гибкость

Вопросы интервьюера

Q: Обязателен ли Primary Key в таблице?

Технически нет, но это сильно рекомендуется. Без Primary Key сложно обновлять/удалять конкретные записи и невозможно создать Foreign Key.

Q: Может ли Primary Key состоять из нескольких столбцов?

Да, это называется составной (composite) Primary Key. Используется для таблиц связи many-to-many.

Q: Что произойдёт при удалении записи, на которую ссылается Foreign Key?

Зависит от настройки: ошибка (RESTRICT), каскадное удаление (CASCADE), или установка NULL.

Q: Почему не использовать email как Primary Key?

Email может измениться, содержит личные данные, занимает много места. Лучше использовать суррогатный ключ (id).

Q: SERIAL vs BIGSERIAL — когда что использовать?

SERIAL до ~2 млрд записей, BIGSERIAL для больших таблиц. UUID для распределённых систем.

NodeJS Back-end Инженер