При изменении порядка сортировки данных в индексах следует помнить, что FOREIGN KEY и соответствующий ему PRIMARY KEY должны использовать одинаковый порядок сортировки в связанных с ними индексах.

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

Наличие или отсутствие индекса совершенно незаметно для пользователя, обращающегося к таблице. Если для какого-либо столбца создан индекс, то СУБД будет автоматически его использовать.

Чтобы при выполнении запросов деактивизировать или, наоборот, активизировать использование определенного индекса, необходимо воспользоваться запросом ALTER INDEX, который имеет следующий формат:

ALTER INDEX имя индекса {ACTIVE INACTIVE};

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

Удаление индекса с заданным именем производится с помощью запроса DROP INDEX, который имеет следующий формат:

DROP INDEX имя индекса;. 4.4. Временные таблицы

Ранее были описаны запросы DDL применительно к постоянным (базовым) таблицам, которые характеризуются тем, что их определение и содержимое существуют в БД до тех пор, пока они не будут удалены явно с помощью соответствующих запросов. Часто в процессе работы возникает необходимость сохранения временных данных (например, промежуточных результатов вычислений в хранимых процедурах). Если хранить такие временные данные в обычных таблицах, то требуются постоянное слежение за содержимым таблиц, а также специфическая организация работы с данными. Более удобно в таком случае использовать временные таблицы.

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

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

CREATE GLOBAL TEMPORARУ TABLE имя временной таблицы

(<определение столбца> [, <определение столбца>;

<тип ограничения>......])

[ON COMMIT {DELETE PRESERVE} ROWS];

Таким образом, данный синтаксис отличается от синтаксиса создания обычных таблиц фразой GLOBAL TEMPORARУ и предложением ON COMMIT.

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

Тип временной таблицы устанавливается с помощью предложения ON

COMMIT.

Если используется ON COMMIT DELETE ROWS, то данные таблицы будут удаляться из БД сразу же после окончания транзакции. Таким образом, таблицы GLOBAL TEMPORARY DELETE хранят записи только до ближайшей команды COMMIT или ROLLBACK, причем не только транзакции, которая их создала, но и любой другой транзакции в этом же подключении. При этом созданные в таблице записи не видны нигде кроме текущей транзакции. После использования как ROLLBACK, так и COMMIT записи во временных таблицах исчезнут , однако в случае COMMIT все изменения, произведенные над обычными таблицами, будут подтверждены.

Следует отметить, что ON COMMIT DELETE ROWS принимается по умолчанию, если предложение ON COMMIT не задано.

Если создадать временную таблицу с помощью следующего запроса: CREATE GLOBAL TEMPORARY TABLE TmpTrans (ID INTEGER not null, NAME VARCHAR (20),

CONSTRAINT PK TmpTrans PRIMARY KEY (ID) ) ON COMMIT DELETE ROWS;,

а затем добавить в нее запись

INSERT INTO TmpTrans VALUES (1, Запись №1);,

то после вставки не следует подтверждать транзакцию, иначе записи пропадут.

Если теперь выполнить следующий запрос: SELECT * FROM TmpTrans;,

то в результате можно получить записи, внесенные во временную таблицу (рис.

4.3).

Рис. 4.3. Результат выборки данных из временной таблицы

После выполнения COMMIT повтор последнего запроса вернет в качестве результата пустую таблицу.

Если используется ON COMMIT PRESERVE ROWS, то данные таблицы после окончания транзакции остаются в БД до конца соединения. Т. е. таблицы

GLOBAL TEMPORARY PRESERVE хранят записи до отсоединения

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

Например, если создадать временную таблицу с помощью следующего запроса:

CREATE GLOBAL TEMPORARY TABLE TmpConn (Id INTEGER NOT NULL, Name VARCHAR (20),

CONSTRAINT PK TmpConn PRIMARY KEY (ID) ) ON COMMIT PRESERVE ROWS; ,

затем добавить в нее запись, например, используя следующий запрос: INSERT INTO TMPCONN

VALUES (1, Запись №1 для текущего соединения);

и подтвердить транзакцию (COMMIT), то в рамках текущего подключения данная запись будет видна из разных транзакций. Если выполнить еще одно подключение к этой же БД (например, запустив еще один экземпляр IBExpert) и выполнить тот же самый запрос INSERT, то ошибки PRIMARY or UNUQIE key constraint (повтор значения первичного ключа) не возникнет. Как только текущее соединение будет закрыто, вставленные данные пропадут.

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

Однако следует учитывать следующие ограничения:

1) ссылки (ограничения внешнего ключа REFERENCES) между постоянной и временной таблицей запрещены;

2) временная таблица с ON COMMIT PRESERVE ROWS не может иметь ссылку на временную таблицу с ON COMMIT DELETE ROWS.

В заключение можно сказать, что временные таблицы могут быть достаточно полезны для приложений, которые формируют сложные отчеты или производят промежуточные вычисления на сервере. Однако использование временных таблиц может замедлять подключение к БД (если использовались таблицы GLOBAL TEMPORARY DELETE) и отключение от нее (если использовались таблицы GLOBAL TEMPORARY PRESERVE) из-за очистки жесткого диска от версий удаленных записей из таблицы.