> Зачем нужен первичный ключ? (Go)

Короткий ответ

Первичный ключ - это уникальный идентификатор строки в таблице, обеспечивающий целостность данных и возможность однозначной адресации записи. Он гарантирует отсутствие дубликатов, служит основой для внешних ключей и оптимизирует доступ через индекс. Без первичного ключа невозможно корректно выполнять операции UPDATE/DELETE по конкретной записи, строить связи между таблицами и поддерживать консистентность данных в реляционной модели.

Подробное объяснение

Первичный ключ решает три фундаментальные задачи:

1. Идентификация - каждая строка получает уникальный идентификатор, по которому её можно найти, обновить или удалить без побочных эффектов на другие записи.

2. Целостность - ограничение UNIQUE + NOT NULL гарантирует, что в таблице не появится двух одинаковых записей с точки зрения бизнес-логики (если ключ естественный) или технической уникальности (если суррогатный).

3. Связность - внешние ключи в других таблицах ссылаются именно на первичный ключ, формируя реляционные отношения. Это позволяет СУБД поддерживать ссылочную целостность на уровне движка, а не только в приложении.

Важный нюанс: первичный ключ автоматически создаёт кластерный (в PostgreSQL - обычный уникальный) индекс. Это ускоряет поиск по ключу, но при вставке в середину таблицы может вызывать page splits. Поэтому выбор типа ключа - это trade-off между скоростью записи и скоростью чтения.

В Go-бэкенде первичный ключ часто маппится на поле структуры с тегом gorm:"primaryKey" или db:"id". При проектировании API идентификатор обычно передаётся в URL path (например, /users/42), и от того, насколько правильно выбран тип ключа, зависит масштабируемость: UUIDv7 лучше для распределённых систем, автоинкремент - для монолита с одной БД.

На практике

В реальных проектах выбор первичного ключа - это инженерное решение:

• Автоинкремент (serial/bigserial) - простой, компактный, но раскрывает количество записей и создаёт проблему при шардировании.
• UUID (v4) - генерируется на клиенте, не требует round-trip к БД, но занимает 16 байт и замедляет вставку из-за случайного распределения.
• UUIDv7 - компромисс: сортируемый во времени, сохраняет преимущества UUID.
• Натуральный ключ (email, passport number) - экономит место, но хрупкий: изменение значения потребует каскадного обновления всех ссылок.

Для Go-сервисов с PostgreSQL я рекомендую BIGINT GENERATED ALWAYS AS IDENTITY для монолита и UUIDv7 для микросервисов. В Java-мире (Spring Boot + Hibernate) аналогично: @GeneratedValue(strategy = GenerationType.IDENTITY) или @UuidGenerator.

Отдельный кейс - составные первичные ключи. Они оправданы для таблиц-связок (many-to-many), где уникальность определяется парой внешних ключей. Но для большинства сущностей лучше суррогатный ключ + уникальный индекс на бизнес-поле.

Пример кода

GO
// GORM-модель с суррогатным ключом
type User struct {
    ID        uint64 `gorm:"primaryKey;autoIncrement"`
    Email     string `gorm:"uniqueIndex;not null"`
    CreatedAt time.Time
}

// UUIDv7 через генерацию на стороне приложения
type Order struct {
    ID        uuid.UUID `gorm:"type:uuid;primaryKey"`
    UserID    uint64    `gorm:"index"`
    Total     decimal.Decimal
    CreatedAt time.Time
}

// Миграция для составного ключа
// CREATE TABLE order_items (
//     order_id   BIGINT NOT NULL,
//     product_id BIGINT NOT NULL,
//     quantity   INT NOT NULL,
//     PRIMARY KEY (order_id, product_id),
//     FOREIGN KEY (order_id) REFERENCES orders(id),
//     FOREIGN KEY (product_id) REFERENCES products(id)
// );

Как отвечать на собеседовании

Начните с назначения, затем переходите к типам и trade-off. Покажите понимание влияния на производительность и архитектуру. Упомяните разницу между естественными и суррогатными ключами, приведите пример из своего опыта. Если спросят про распределённые системы - расскажите про UUIDv7 и snowflake-подходы. Хорошо, если вы упомянете, что первичный ключ - это не только про уникальность, но и про физическое хранение (кластерный индекс в InnoDB, heap в PostgreSQL). Завершите практическим советом: для большинства случаев берите суррогатный ключ, а бизнес-уникальность обеспечивайте отдельными уникальными индексами.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание реляционной модели и ограничений целостности;
• умение взвешивать trade-off между типами ключей;
• знание внутреннего устройства СУБД (индексы, кластеризация);
• способность применить теорию к реальной архитектуре (шардирование, микросервисы);
• осознание разницы между технической и бизнес-уникальностью.

Для senior-уровня важно показать, что вы не просто знаете определение, а принимали решения в продакшене и понимаете последствия выбора.

Типичные ошибки

• Ответ только "для уникальности строк" - слишком поверхностно, не показывает понимание связей и индексов.
• Утверждение, что первичный ключ обязателен в каждой таблице - в PostgreSQL можно создать таблицу без PK, хотя это плохая практика.
• Игнорирование влияния на производительность вставки (UUIDv4 vs автоинкремент).
• Путаница между первичным ключом и уникальным индексом: уникальный индекс не обязан быть NOT NULL и не используется для внешних ключей по умолчанию.
• Предложение натурального ключа без анализа стабильности значения (например, email меняется).
• Отсутствие упоминания кластерного индекса в MySQL/InnoDB - для senior это критично.