InterBase: тормозология и глюконавтика
Страница 16. Когда план писать нельзя
Страница 16 из 38

Когда план написать нельзя

Нет добра без худа. Особенно в interbase. То если есть возможность писать планы, то есть места, где это не получится. Таких мест, а точнее, видов мест, по большому счёту я могу указать три (может быть, я что-то упустил):
  1. Хранимые процедуры. Это ограничение стало менее актуальным в 5.x, но тем не менее. Во-первых в interbase до 5.x Вы просто не сможете перебэкапить базу, если сошлётесь на индекс из процедуры. Хотя в остальном всё будет работать нормально. Однако с учётом глюков, работа с такой базой ничем хорошим не кончится. Пятый interbase перебэкапливает такую базу нормально, но надёжно сослаться на системный индекс по-прежнему невозможно. То есть после перемены его номера процедура откажет. В крайнем случае придётся создать дублирующий. Сгенерировать динамический запрос внутри процедуры так же нереально.
  2. "Блокирующие" планирование представления с distinct или прочими неприятностями.
  3. Использование на клиенте компонентов, которые не позволяют рулить планами. Классический (и клинический) пример TTable в Delphi или DbiOpenTable() в BDE, что вообще-то одно и то же. О чём тоже есть отдельный раздел.
Самое неприятное в этих ситуациях то, что они не могут дать гарантированной скорости, в отличие от планов. Но можно повысить вероятность хорошей работы. Во-первых, надо всеми средствами отловить непосредственно сами запросы. Далее нужно исследовать их в ISQL и сопоставить с повадками планировщика interbase. После чего попытаться переформулировать запросы в процедурах или настройки компонентов так, чтобы по возможности ограничить инициативу interbase "хорошими" вариантами.

В процедурах бывает полезно расщепить запрос на несколько вложенных циклов for select. Каждый цикл должен быть как можно проще и его условия должны максимально соответствовать индексам. Или наоборот, создать индексы под условия. В идеале каждый запрос должен образовывать одну "реку", охватываемую одним индексом. При этом запросы должны как можно жёстчё фильтроваться, чтобы минимизировать количество итераций.

В клиентских компонентах следует по возможности ссылаться не на представления, а на хранимые таблицы. Если есть возможность изменять структуру таблиц, то лучше сделать так, чтобы поля, не участвующие в наиболее важных запросах, хранились в отдельной таблице. Подсоединяемые таблицы лучше всего трансформировать в вычисляемые поля, вычитываемые по текущей записи заранее подготовленным запросом (в проекте "Архив" - dmShareDatabase.QLookup()).
 
« Предыдущая статья