Перейти на PRO

Какие виды первичных ключей используются в реляционных базах данных?

Тип вопроса: Базы данных и SQL Вероятность: 10% Категория: QA Тестировщик

Ответ

Первичный ключ (PRIMARY KEY) — это атрибут или набор атрибутов, однозначно идентифицирующих каждую запись в таблице. Основные виды:

  1. Естественный ключ (Natural Key)

    • Описание: Уже существующее в предметной области поле с уникальными и неизменными значениями.
    • Пример: Номер паспорта, серийный номер устройства, email (если гарантирована уникальность).
    • Плюсы: Имеет бизнес-смысл, не требует дополнительного поля.
    • Минусы: Может измениться (например, паспорт), часто является строковым и менее эффективен для индексов, чем целочисленный ключ.

  2. Суррогатный ключ (Surrogate Key)

    • Описание: Искусственно созданный идентификатор, не имеющий смысла в предметной области. Добавляется исключительно для нужд базы данных.
    • Пример: Автоинкрементное целое число (AUTO_INCREMENT в MySQL, SERIAL в PostgreSQL, IDENTITY в SQL Server).
    • Плюсы: Гарантированно уникален, неизменен, компактен и эффективен для соединений (JOIN).
    • Минусы: Не несёт бизнес-смысла.
-- Пример таблицы с суррогатным ключом
CREATE TABLE users (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, -- Суррогатный ключ
    email VARCHAR(255) NOT NULL UNIQUE, -- Естественный ключевой кандидат
    username VARCHAR(50) NOT NULL
);
  1. Составной ключ (Composite Key)
    • Описание: Первичный ключ, состоящий из двух или более полей таблицы.
    • Применение: Часто используется в промежуточных таблицах для связи многие-ко-многим, где уникальность обеспечивает комбинация внешних ключей.
-- Пример составного первичного ключа в таблице-связке
CREATE TABLE order_items (
    order_id INT NOT NULL REFERENCES orders(id),
    product_id INT NOT NULL REFERENCES products(id),
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, product_id) -- Составной ключ
);

Выбор подхода: В современных OLTP-системах суррогатные ключи являются де-факто стандартом из-за своей производительности и простоты. Естественные ключи используются, когда есть гарантированно неизменный уникальный атрибут, а составные — для моделирования сложных отношений.

Ответ 18+ 🔞

Слушай, ну вот сидишь ты, проектируешь свою базу данных, и тут бац — вопрос: а какой, блядь, первичный ключ выбрать? Это ж как выбрать тапки: можно взять свои старые, проверенные (естественный ключ), а можно купить новые, безликие, но удобные (суррогатный). А можно вообще надеть сразу два разных, скрестить ежа с ужом (составной ключ). Давай разбираться, пока не начался пиздец.

1. Естественный ключ (Natural Key) Ну, это типа когда ты берешь уже готовое, реальное поле из жизни. Номер паспорта, серийник от телевизора, email пользователя (если он у тебя один на всех, как последняя конфета).

  • Плюсы: Имеет смысл, блядь. Не надо выдумывать хуйню, всё и так понятно.
  • Минусы: А вдруг этот твой «паспорт» поменяется? Или email? Или окажется, что это строка длиной в овердохуища символов, и индексы на ней будут тормозить, как черепаха в сиропе. Рисковано, ёпта.

2. Суррогатный ключ (Surrogate Key) А вот это наш вариант, бронежилет для базы данных! Это искусственный, нарисованный идентификатор, который не имеет никакого отношения к реальному миру. Просто цифра, которая растет сама по себе. Идеальный солдат: уникальный, неизменный, маленький и быстрый.

  • Плюсы: Гарантированно уникален, не меняется никогда, и для джойнов (JOIN) — просто песня. Производительность ебать.
  • Минусы: Сам по себе — полная бессмыслица. Цифра и цифра. Бизнес-логике на него похуй.
-- Смотри, как просто и элегантно
CREATE TABLE users (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, -- Вот он, красавец, суррогатный ключ. Автоинкремент, ёба!
    email VARCHAR(255) NOT NULL UNIQUE, -- Это у нас естественный кандидат, но ключом не стал
    username VARCHAR(50) NOT NULL
);

3. Составной ключ (Composite Key) А это когда ты такой: «А давайте я возьму не один столбец, а сразу два (или три, или пять)!». Уникальность будет достигаться их комбинацией. Чаще всего это нужно в таблицах-связках, где встречаются много-ко-многим.

  • Применение: Таблицы типа «заказы_товары», «студенты_курсы». Там, где пара (order_id, product_id) — это и есть уникальная хуйня.
-- Таблица для заказов, где одна позиция — это комбинация заказа и товара
CREATE TABLE order_items (
    order_id INT NOT NULL REFERENCES orders(id),
    product_id INT NOT NULL REFERENCES products(id),
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, product_id) -- Вот он, составной зверь! Оба поля вместе — и есть ключ.
);

Итог, блядь: В 99% современных систем все берут суррогатные ключи. Это надежно, быстро и не парит мозг. Естественные — на свой страх и риск, если есть железобетонный, неизменный атрибут. А составные — для специальных случаев, когда нужно связать две сущности в одну уникальную пару. Выбирай с умом, а то потом будешь как Герасим — метаться и мучиться.

© ХакСобесов, 2026
support@hacksobesov.com