Этот вопрос проверяет понимание связи между ограничением UNIQUE и индексами в реляционных базах данных, что важно для проектирования эффективных схем.
В реляционных базах данных ограничение UNIQUE гарантирует, что все значения в указанном столбце (или комбинации столбцов) будут различаться. Для эффективной проверки этого правила при каждой операции вставки или обновления система должна быстро определить, существует ли уже такое значение. Именно для этого используется индекс.
Когда вы создаёте ограничение UNIQUE, СУБД неявно создаёт уникальный индекс на соответствующих столбцах. Этот индекс структурирован (чаще всего как B-дерево) для быстрого поиска. При попытке вставить новую запись система проверяет индекс на наличие ключа — если он найден, операция отклоняется с ошибкой нарушения уникальности.
Вот как это выглядит на практике:
-- Создание таблицы с UNIQUE constraint в PostgreSQL/MySQL
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE, -- Автоматически создаст уникальный индекс
username VARCHAR(100) UNIQUE
);
-- Проверка существующих индексов (пример для PostgreSQL)
SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'users';
-- Результат покажет индексы, например, users_email_key, users_username_keyWHERE email = 'test@example.com').UNIQUE создаёт "индекс" в логическом смысле, но он может не отображаться отдельно в системных таблицах. В Oracle вы можете явно указать, использовать ли существующий индекс или создать новый.Вывод: Ограничение UNIQUE практически всегда подразумевает создание уникального индекса, что полезно как для обеспечения целостности данных, так и для оптимизации запросов. При проектировании базы данных стоит учитывать это, чтобы избежать создания избыточных индексов вручную.