Какие знаешь виды первичных ключей?

Виды первичных ключей в базах данных

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

Основные виды первичных ключей

1. Простой (естественный) ключ

Это ключ, состоящий из одного атрибута (столбца), который имеет естественное бизнес-значение и уникален в контексте системы.

• Примеры: номер паспорта, VIN-код автомобиля, серийный номер устройства, ISBN книги.
• Преимущества для QA: Значение ключа имеет смысл, его можно использовать для ручных проверок и понимания данных.
• Риски: Бизнес-логика может измениться, и уникальность может быть нарушена (например, форматы номеров). Требует тщательной валидации на этапе ввода.

CREATE TABLE Passport (
    passport_number VARCHAR(20) PRIMARY KEY, -- Естественный ключ
    full_name VARCHAR(100),
    issue_date DATE
);

2. Составной (композитный) ключ

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

• Примеры: В таблице ClassSchedule ключ (classroom_id, day_of_week, lesson_time). В таблице заказов товаров OrderItems ключ (order_id, product_id).
• Преимущества для QA: Позволяет точно смоделировать сложные бизнес-правила. Критически важен для тестирования связей "многие-ко-многим".
• Риски: Усложняет написание JOIN-запросов и может снижать производительность при очень большой ширине ключа.

CREATE TABLE Order_Items (
    order_id INT,
    product_id INT,
    quantity INT,
    PRIMARY KEY (order_id, product_id) -- Составной ключ
);

3. Суррогатный (искусственный) ключ

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

• Примеры: ID с автоинкрементом (AUTO_INCREMENT в MySQL, SERIAL в PostgreSQL, IDENTITY в SQL Server), GUID/UUID.
• Преимущества для QA:

    *   **Стабильность**: Не зависит от изменений бизнес-логики.
    *   **Производительность**: Как правило, это целочисленное поле, индексируется очень эффективно.
    *   **Конфиденциальность**: В URL или API-запросах не раскрывается бизнес-информация (в отличие от, скажем, номера договора).

• Недостаток: Усложняет ручное сопоставление данных в логах или сырых выборках без дополнительных JOIN.

CREATE TABLE Users (
    user_id BIGINT AUTO_INCREMENT PRIMARY KEY, -- Суррогатный ключ (автоинкремент)
    email VARCHAR(255) UNIQUE NOT NULL,
    username VARCHAR(50)
);

4. Ключ на основе GUID/UUID

Это разновидность суррогатного ключа, использующая глобально уникальный идентификатор (128-битное число).

• Преимущества для QA и разработки:

    *   **Глобальная уникальность**: Можно безопасно генерировать ID в распределенных системах без координации с центральной БД.
    *   **Безопасность**: Сложнее предсказать следующий ID, чем в случае с автоинкрементом.

• Недостатки: Занимает больше места (16 байт), может фрагментировать индексы, неудобен для чтения человеком.

CREATE TABLE Distributed_Log (
    log_id UUID DEFAULT gen_random_uuid() PRIMARY KEY, -- Ключ-UUID (пример для PostgreSQL)
    event_data JSONB
);

Практическое значение для QA-инженера

Понимание этих типов напрямую влияет на мою работу:

• Тест-дизайн: При создании тестовых данных я осознанно выбираю стратегию генерации ключей. Для суррогатных — могу игнорировать значение, для естественных — должен обеспечить валидный формат и уникальность.
• Проверка целостности данных: Я проверяю, что ограничение PRIMARY KEY действительно предотвращает вставку дубликатов (NULL значения отклоняются автоматически). Для составных ключей тестирую комбинации дублирования.
• Тестирование API и интеграций: В REST API суррогатный id часто используется в путях (/api/users/{id}). Я проверяю обработку несуществующих ID, некорректных форматов (например, строки вместо числа для INT).
• Миграции и слияния данных: При тестировании сценариев миграции баз данных ключевой риск — конфликт суррогатных ключей (например, при слиянии двух веток разработки). Понимание типов ключей помогает спланировать такие тесты.
• Анализ логов и ошибок: Зная тип ключа, я быстрее интерпретирую ошибки вроде Duplicate entry '12345' for key 'PRIMARY' или Cannot insert NULL into primary key.

Вывод для собеседования: В современных сложных приложениях чаще всего используется комбинация ключей. Основная таблица Users имеет суррогатный id, а для таблицы связей User_Roles используется составной ключ (user_id, role_id). Естественные ключи (email, sku) при этом часто защищаются ограничением UNIQUE, что также требует тщательного тестирования на уникальность и обработку коллизий. Моя задача как QA — понимать эти модели данных, чтобы создавать эффективные тесты, покрывающие как "счастливые пути", так и краевые случаи, связанные с целостностью уникальных идентификаторов.