Блог

У меня есть таблица, которая содержит идентификаторы и электронные письма. Для простоты предположим, что идентификатор — это номер строки. Оба этих столбца уникальны — никакие две строки не будут иметь одинаковый идентификатор, и никакие две строки не будут иметь одинаковый адрес электронной почты. Мне нужно иметь возможность запрашивать быстрый идентификатор по электронной почте и электронную почту по идентификатору.

Если бы я сам программировал эту схему, в дополнение к основной таблице (которая индексируется по идентификатору), я бы сохранил хэш-таблицу, в которой в качестве ключей были бы электронные письма. Это обеспечило бы O (1) для поиска в обоих направлениях.

Вот как я планирую создавать свои таблицы:

 CREATE TABLE main_table (
    id      INT AUTO_INCREMENT,
    email   VARCHAR(256) NOT NULL,
            ...
    PRIMARY KEY(id)
    UNIQUE(email)
);

CREATE TABLE id_by_email (
    email   VARCHAR(256),
    id      INT,
    PRIMARY KEY(email),
    FOREIGN KEY(email) REFERENCE main_table(email),
    FOREIGN KEY(id) REFERENCE main_table(email),
);
  

Будет ли эта настройка вообще работать? И если это произойдет, приведет ли это к поиску O (1), к которому я стремлюсь?

Поиск в индексе B-дерева O(log n) . Для всех практических целей это достаточно быстро. В конце концов, журнал в 1 000 000 составляет всего около 30.

Кроме того, с индексом вам не нужно беспокоиться о том, помещается ли хэш-таблица в память. И SQL поддерживает индекс даже при изменении данных.