Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

Пример

В этом примере создается уникальный индекс для трех столбцов таблицы инвентаризации для гарантирования того, что система хранит не более одной строки для каждого размера и цвета элемента:

CREATE UNIQUE INDEX STK_SIZE_COLOR_UQX

ON STOCK_ITEM (PRODUCT_ID, SIZE, COLOR);

Заметьте, что уникальный индекс не является ключом. Если вам требуется уникальный ключ для ссылочных целей, используйте для этого ограничение UNIQUE для столбца (столбцов). Подробнее об использовании ограничения UNIQUE см. главу 16.

Поиск дубликатов

Конечно, невозможно создать уникальный индекс для столбца, который уже содержит дублирующие значения. Перед определением уникального индекса используйте оператор SELECT для поиска дублирующих элементов в таблице. Например, до создания уникального индекса для PRODUCT_NAME В таблице PRODUCT следующая проверка будет показывать любые дубликаты в этом столбце:

SELECT PRODUCT_ID, UPPER(PRODUCT_NAME) FROM PRODUCT

GROUP BY PRODUCT_ID, UPPER(PRODUCT_NAME)

HAVING COUNT(*) > 1;

! ! !

ПРИМЕЧАНИЕ. Перевод значения столбца в верхний регистр, чтобы сделать поиск не чувствительным к регистру, не является необходимым с точки зрения уникальности данных. Тем не менее, если уникальность была "поломана" вводом ошибочных данных, мы можем отыскать все неправильные записи.

. ! .

Как вы поступите с дубликатами, зависит от того, что они означают в ваших бизнес- правилах, и от количества дубликатов, которые нужно уменьшить. Обычно, храни- мая процедура является наиболее эффективным способом это обработать. Хранимые процедуры подробно обсуждаются в главах 28-30.

ASC[ENDING] или DESC[ENDING]

Ключевые слова ASC[ENDING] и DESC[ENDING] определяют вертикальный порядок сортировки индекса, ASC задает сортировку индекса от меньшего к большему. Оно является значением по умолчанию и может быть опущено, DESC сортирует значения от большего к меньшему и должно быть указано, если требуется убывающий индекс. Убывающий индекс может быть полезным для запросов, которые отыскивают наибольшие значения (наибольший возраст, самый последний, самый большой и т.д.), а также при упорядоченном поиске или для выходных данных, которые должны быть отсортированы в убывающем порядке.

Пример

Следующее определение создает убывающий индекс для таблицы в базе данных employee:

CREATE DESCENDING INDEX DESC_X ON SALAR Y_HISTORY (CHANGE_DATE);

Оптимизатор будет использовать этот индекс в запросах, подобных следующему, который возвращает номера служащих и их оклады для десяти последних служащих, которым были повышены оклады:

SELECT FIRST 10 EMP_NO, NEW_SALARY

FROM SALARY_HISTORY

ORDER BY CHANGE_DATE DESCENDING;

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

CREATE ASCENDING INDEX ASCEND_X ON SALARY_HISTORY (CHANGE_DATE) ;

Индексы для нескольких столбцов

Если вашим приложениям часто требуется поиск, упорядочение или группировка по некоторой группе из нескольких столбцов в конкретной таблице, будет полезно создать индекс для нескольких столбцов (также называемый составным или композитным индексом).

Оптимизатор будет использовать подмножество сегментов такого индекса для оптимизации запроса, если порядок слева направо, в котором запрос обращается к столбцам в предложении ORDER BY, соответствует порядку слева направо в списке столбцов, определенному в индексе. При этом для запросов не требуется иметь в точности такой же список столбцов, как определено в индексе, чтобы индекс мог быть использован оптимизатором. Индекс также может быть использован, если подмножество

столбцов в предложении ORDER BY начинается с первого столбца индекса, определенного для нескольких столбцов.

Firebird может использовать один элемент составного индекса для оптимизации поиска, если все предшествующие элементы индекса также используются. Рассмотрим сегментированный индекс для трех столбцов col_w, col_x и col_y в том порядке, как показано на рис. 18.1.

Рис. 18.1. Сегментированный индекс

Этот индекс будет использован оптимизатором для следующего запроса:

SELECT <список столбцов> FROM ATABLE

ORDER BY COL_w, COL_X;

Он не будет использован для следующих запросов:

SELECT <список столбцов> FROM ATABLE

ORDER BY COL_x, COL_y;

/**/

SELECT < список столбцов> FROM ATABLE

ORDER BY COL_x, COL_w;

Предикаты OR в запросах