Может ли primary key быть составным?

Да, первичный ключ (PRIMARY KEY) может быть составным (композитным)

Составной первичный ключ (composite primary key) — это ключ, состоящий из двух или более столбцов таблицы, которые в комбинации уникально идентифицируют каждую запись. Это фундаментальная концепция в проектировании реляционных баз данных, широко поддерживаемая всеми современными СУБД, включая MySQL, PostgreSQL, Oracle и SQL Server.

Зачем нужен составной первичный ключ?

1. Естественная идентификация записей: В реальных данных часто нет одного уникального столбца, но комбинация нескольких полей обеспечивает уникальность.
2. Моделирование связей "многие-ко-многим": В ассоциативных (связующих) таблицах составной ключ часто состоит из внешних ключей на связываемые таблицы.
3. Обеспечение бизнес-правил: Гарантирует уникальность по логике предметной области (например, уникальность пары user_id + email в таблице контактов пользователя).

Пример создания и использования в SQL

-- Пример 1: Связующая таблица "многие-ко-многим"
CREATE TABLE user_roles (
    user_id INT NOT NULL,
    role_id INT NOT NULL,
    assigned_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (user_id, role_id), -- Составной первичный ключ
    FOREIGN KEY (user_id) REFERENCES users(id),
    FOREIGN KEY (role_id) REFERENCES roles(id)
);

-- Пример 2: Таблица с естественным ключом
CREATE TABLE course_registrations (
    student_id INT NOT NULL,
    course_code VARCHAR(20) NOT NULL,
    semester VARCHAR(10) NOT NULL,
    grade DECIMAL(3,2),
    PRIMARY KEY (student_id, course_code, semester) -- Три колонки в ключе
);

Особенности работы с составными первичными ключами

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

-- Правильно: все поля первичного ключа должны быть заполнены
INSERT INTO user_roles (user_id, role_id) VALUES (1, 5);
INSERT INTO user_roles (user_id, role_id) VALUES (1, 6); -- Разрешен другой role_id
INSERT INTO user_roles (user_id, role_id) VALUES (2, 5); -- Разрешен другой user_id

-- Ошибка: дублирование комбинации (1, 5)
INSERT INTO user_roles (user_id, role_id) VALUES (1, 5);

Запросы и JOIN

-- Поиск по полному ключу (самый эффективный)
SELECT * FROM user_roles WHERE user_id = 1 AND role_id = 5;

-- Поиск по части ключа (используется префикс индекса)
SELECT * FROM user_roles WHERE user_id = 1;

-- JOIN с составным ключом (гипотетический пример)
SELECT u.name, r.role_name 
FROM user_roles ur
JOIN users u ON ur.user_id = u.id
JOIN roles r ON ur.role_id = r.id;

Плюсы составных первичных ключей

✅ Семантическая корректность: Отражают реальные бизнес-правила уникальности.
✅ Сокращение избыточности: Избегают создания искусственных идентификаторов, когда естественный ключ уже существует.
✅ Улучшенная производительность: Часто служат отличным clustered индексом для частых запросов по этим полям.
✅ Целостность данных: Гарантируют уникальность по комбинации полей на уровне БД.

Минусы и ограничения

❌ Сложность миграций: Изменить структуру составного ключа сложнее, чем одиночного.
❌ Влияние на индексы: Больший размер ключа (~10-20% от размера строки в InnoDB).
❌ Запросы по части ключа: WHERE с неполным ключом может быть менее эффективен.
❌ Внешние ключи: Для ссылки на составной первичный ключ нужен составной внешний ключ.

Практические рекомендации для PHP-разработчика

// Пример работы с составным ключом в Laravel Eloquent
class UserRole extends Model
{
    // Важно: отключаем автоинкрементный ID
    public $incrementing = false;
    
    // Указываем поля первичного ключа как массив
    protected $primaryKey = ['user_id', 'role_id'];
    
    // Остальная модель...
}

// Пример запроса
$userRole = UserRole::find([1, 5]); // Поиск по составному ключу

// Пример вставки
$userRole = new UserRole();
$userRole->user_id = 1;
$userRole->role_id = 5;
$userRole->save(); // Проверяет уникальность (1, 5)

Когда использовать составные ключи?

1. Связующие таблицы для отношений "многие-ко-многим".
2. Таблицы журналов/аудита, где важен уникальный набор параметров.
3. Справочники с естественными ключами (регионы, классификаторы).
4. Временные ряды, где уникальность определяется объектом + временем.

Когда предпочесть суррогатный ключ?

• Если бизнес-правила могут измениться.
• Если ключ слишком большой (4+ поля) или содержит строки переменной длины.
• Для ORM, которые плохо поддерживают составные ключи.

Вывод

Составные первичные ключи — это мощный инструмент, который следует использовать осознанно. Они отлично подходят для связующих таблиц и случаев с естественной уникальностью комбинации полей. Однако для основных сущностей (пользователи, товары) часто предпочтительнее суррогатные ключи (автоинкрементные id) из-за их простоты и гибкости. Выбор зависит от конкретных требований предметной области, производительности и используемого стека технологий.