Какие знаешь требования для ключа?

Требования для ключей в базе данных

Ключи являются критическим аспектом проектирования баз данных. Они обеспечивают целостность данных, производительность запросов и связывают таблицы друг с другом. Рассмотрю все типы ключей и их требования.

1. Primary Key (Первичный ключ)

Определение: уникальный идентификатор каждой строки в таблице. В таблице может быть только ОДИН первичный ключ.

Требования для Primary Key:

CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL
);

-- Или составной первичный ключ
CREATE TABLE order_items (
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, product_id)
);

1. Уникальность — каждое значение должно быть УНИКАЛЬНЫМ
2. Не NULL — первичный ключ НИКОГДА не может быть NULL
3. Стабильность — значение должно быть неизменяемым
4. Простота и минимальность — ключ должен быть простым и коротким
5. Индексирование — первичный ключ ВСЕГДА индексируется автоматически

2. Unique Key (Уникальный ключ)

Определение: гарантирует уникальность значений столбца(ов), но в отличие от первичного ключа, может быть НЕ один, и может содержать NULL.

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    username VARCHAR(255) NOT NULL UNIQUE,
    email VARCHAR(255) UNIQUE,
    phone VARCHAR(20)
);

Требования:

• Уникальность значений
• Может содержать NULL (в отличие от primary key)
• Может быть составным (composite unique key)

3. Foreign Key (Внешний ключ)

Определение: связь между таблицами. Значение внешнего ключа должно существовать в первичном ключе целевой таблицы.

CREATE TABLE customers (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(id)
);

Требования:

• Ссылается на уникальный ключ целевой таблицы
• Значение либо существует в целевой таблице, либо NULL
• Действия при удалении/обновлении (CASCADE, SET NULL, RESTRICT)
• ВСЕГДА индексировать foreign keys

4. Natural Key vs Surrogate Key

Surrogate Key (рекомендуется):

• Искусственный ID (AUTO_INCREMENT, UUID)
• Простой и миниатюрный (8 байт BIGINT)
• Типа BIGINT вместо INT (чтобы не переполниться)
• Стабилен и не меняется

Natural Key:

• Использует реальные данные (email, username, SKU)
• Может изменяться (опасно для FK)
• Может быть громоздким

5. Требования для составного (Composite) ключа

• Все столбцы должны быть NOT NULL
• Комбинация столбцов должна быть уникальной
• Требует реализации equals() и hashCode() в Java
• Избегай если возможно (сложность > простота)

6. Performance требования для ключей

• Минимальный размер: BIGINT (8 байт) лучше чем VARCHAR(36)
• Индексирование: все ключи должны быть индексированы
• Foreign keys необходимо индексировать вручную
• Не использовать в сортировке без необходимости

Best Practices для ключей в production

1. ВСЕГДА используй Surrogate Key с AUTO_INCREMENT или UUID
2. Natural keys только как UNIQUE constraints
3. Foreign keys ВСЕГДА индексируй вручную
4. Составные ключи редко — избегай если возможно
5. Никогда не меняй первичный ключ — это ломает ссылки
6. Используй CASCADE для целостности данных

В production я использую BIGINT surrogate keys с AUTO_INCREMENT, UNIQUE constraints для натуральных ключей (email, username), и Foreign Keys с CASCADE для целостности данных. Это даёт оптимальный баланс между производительностью и надёжностью.