Последовательные файлы

Последовательный файл, или куча, является наиболее удобной структурой для хранения данных в следующих случаях:

1. Данные загружаются в таблицу крупными блоками.

2. Весь файл таблицы занимает несколько страниц.

3. При каждом обращении к таблице выборке подлежат все ее кортежи.

4. Таблица имеет дополнительные структуры поиска — например, индекс по ключу.

Файлы последовательной структуры не эффективны, если доступ необходим к отдельным- кортежам таблицы.

Хешированные файлы

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

• Выборка кортежей из таблицы осуществляется по шаблонам подстановки, в которые входит и значение поля перемешивания. Например, выборка сведений обо всех сдаваемых в аренду объектах, шифр которых начинается с символов SG.

• Выборка кортежей из таблицы осуществляется по заданному диапазону значения поля, которое входит в значение поля перемешивания.

• Выборка кортежей из таблицы осуществляется по значению поля, отличного от поля перемешивания.

• Доступ к кортежам необходимо выполнять только по части поля перемешивания.

Например, если перемешать таблицу Property_for_Rent (Недвижимость_в_аренду) по значениям атрибутов Rooms (Комнаты) и Rent (Арендная_плата), то механизм хеширования нельзя будет использовать для поиска кортежей по значению только атрибута Rooms (Комнаты). В этом случае требуемый кортеж может быть найден только в результате выполнения линейного поиска.

Индексно-последовательные файлы

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

Двоичные деревья

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

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

7.3.3. Определение вторичных индексов.

Вторичные индексы представляют собой механизм определения в таблицах базы данных дополнительных ключей, которые предназначены для повышения эффективности выборки данных. Например, файл таблицы Property_for_Rent (Недвижимость_в_аренду) может быть перемешан по атрибуту номера сдаваемого в аренду объекта Рпо (Код_недвижимости), в результате чего будет создан первичный индекс этой таблицы. Однако достаточно часто требуется иметь доступ к данным таблицы и по значению атрибута Rent (Арендная_плата). Поэтому для атрибута Rent (Арендная_плата) следует создать вторичный индекс. Данная задача может быть решена с помощью следующего SQL-оператора:

CREATE INDEX property_rent_index ON property_for_rent (rent )

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

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

2. Избегайте создания индексов для небольших таблиц.

3. Создавайте вторичный индекс для любого атрибута, интенсивно используемого в качестве вторичного ключа.

4. Создавайте вторичный индекс для любого интенсивно используемого внешнего ключа.

5. Избегайте создания вторичных индексов для атрибутов или таблиц, подвергаемых частым обновлениям.

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

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