(При этом числовое значение столбца является хеш-ключом, и никакой алгоритм не задействуется).

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

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

Индексные кластеры

В предыдушем разделе мы упоминали о кластерах (поскольку для хеширования необходимо, чтобы таблица находилась в кластере), но так и не объяснили, что же это такое. Кластеризация - это попытка разместить рядом, в одном блоке данных, строки, доступ к которым осуществляется при помощи одинакового значения ключа. Ключ может быть либо хеш-ключом, либо индексным. Если это хеш-ключ, то физическое размещение строк определяется хеширующей функцией. Если это индексный ключ, то для идентификации адреса блока данных (как всегда) используется индекс, имеющий структуру В*-дерева, но строки с одинаковым ключевым значением размещаются в одном блоке или нескольких связанных блоках. Строки, которые хранятся в индексном кластере, не обязательно должны принадлежать одной таблице. Индексные кластеры можно использовать для хранения дочерних строк с родительской, что должно существенно повысить производительность при выполнении соединения этих таблиц.

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

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

Мы рекомендуем применять кластеры только в следующих, очень специфических случаях:

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

На кластерный ключ всегда приходится более одной строки (поскольку в противном случае сгодится и обычная индексированная таблица).

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

Частота DML-обращений к данным мала (поскольку в противном случае плохая производительность DML-операций в кластеризованных таблицах повлияет на всю систему).

Даже в этих слугаях выигрыш в производительности, как правило, не очень высок. В то же время плохо построенный кластер может существенно снизить производительность приложения. Поэтому будьте осторожны! Однако несмотря на это, Oracle интенсивно использует индексные кластеры в оперативном словаре данных. Если хотите посмотреть, насколько интенсивно, - найдите файл sql.bsq, который на Unix-платформах находится в каталоге $ORACLE HOME/dbs, и просмотрите его.

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

CREATE CLUSTER cust comments cluster {cust id VARCHAR2(8)) STORAGE ... INDEX;

CREATE INDEX cust cominents cust id ON CLUSTER cust coniinents cluster STORAGE ...

CRATE TABLE cust comments

( cust id VARCHAR2(8) NOT NULL REFERENCES customers

, enrty# NUMBER NOT NULL

, date entered DATE NOT NULL

, entered by VARCHAR2(8) NOT NULL REFERENCES operators

, comment text VARCHAR2(80) NOT NULL

, PRIMARY KEY (cust id, entry*)

) CLUSTER cust cominents cluster (cust id) ;

Эта таблица кластеризована по столбцу CUST ID, и все комментарии для любого данного клиента будут расположены либо в одном блоке, либо (если их много) в связанных блоках, и их можно выбрать за одну операцию поиска по индексу с помощью следующего запроса:

SELECT date entered , entered by , comment text

FROM cust comments WHERE cust id = :this cust ORDER BY entry* DESC;

Обратите внимание, что ограничение PRIMARY KEY в операторе CREATE TABLE закомментировано, чтобы избежать создания второго индекса. Этот прием следует применять очень осторожно; он заметно снижает затраты при вставке строк в таблицу, но оставляет эту структуру уязвимой для ошибок приложений. Такая форма однотабличного кластера для очень больших таблиц обычно не используется, но может быть полезна в приложении, где;

очень немногие записи о клиентах имеют комментарии;

снабженные комментарием записи имеют, как правило, более одного комментария;

при выборке комментариев для данного клиента выбираются все комментарии.