Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

В "SQL for Smarties" Joe Celco предлагает интересные решения для хранения и поддержки древовидных структур в реляционных базах данных (Morgan Kaufmann, 1999).

Многие аспекты плана, сконструированного внутренне оптимизатором, не видны в плане, показанном в isql и недоступны через синтаксис предложения PLAN для пользовательских планов. Синтаксис показывает только подмножество реального плана, которому будет следовать сервер при выполнении запроса.

Поскольку база данных примера не имеет таблиц без индексов, некоторые примеры в этом разделе используют специально описанные неиндексированные версии таблиц EMPLOYEE, PROJECT и DEPARTMENT, названные EMPLOYEE1, PROJECT1 и Departments соответственно. Скрипт с именем NO_INDEXES.SQL для создания этих таблиц может быт загружен с http://www.apress.com.

Другой причиной использования алиасов при задании запросов и планов является то, что, скорее всего, подобная согласованность будет поддерживаться в следующих версиях Firebird.

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

Оптимизатор InterBase, Firebird 1.0 и 1.5 считает составные индексы более селективными, чем они есть на самом деле. В этом виновата особенность подсчета селективности, которая производится целиком для всего ключа. В Firebird 2.0 селективность составных индексов учитывается отдельно по каждому сегменту составного ключа, что позволяет избежать сильных проколов в оптимизации запросов. - Прим. науч. ред.

Подобное дополнительное условие может привести к тому, что вообще никакие индексы не будут использоваться. Более правильным в случае множества условий поиска является "отключение" низкоселективного индекса для отдельного столбца путем превращения условия сравнения в вычисляемое: для числовых столбцов - where field+0 = value, для строковых - where field || '' = value. - Прим. науч. ред.

В этом случае также желателен и триггер BEFORE UPDATE. - Прим. перев.

Theo Haerder and Andreas Reuter, "Principles of Transaction-Oriented Database Recovery", ACM Computing Surveys 15(4) (1983): 287-317.

Andreas Reuter and Jim Gray, Transaction Processing Concepts and Techniques (San Francisco, С A: Morgan Kaufmann, 1993).

Программисты API. смотрите в TP В константу isc_tpb_no_auto_undo.

Спасибо, Ann Harrison!

В оригинале не совсем верно выбраны термины. Никакой "таблицы", конечно, нет. Есть битовый массив, который меняется при изменении состояния транзакций и который копируется в память (частично) при старте транзакций SNAPSHOT. Также TIP не может быть "раздут", поскольку битовый массив просто растет в размерах при старте каждой новой транзакции и строится заново при очередном восстановлении (restore). Размер TIP равен Next Transaction / 4 (в байтах). - Прим. науч. ред.

Здесь и далее в тексте практически не упоминается важный параметр Oldest Snapshot Transaction (OS Г). - Прим, науч. ред.

Хорошо понимать цикл жизни транзакций в Firebird, если вы работаете и с другими реляционными СУБД, например, с PostgreSQL, которая имитирует многоверсионную архитектуру Firebird.

Во всех версиях Firebird и в InterBase до версии 7.1 sweep срабатывает, когда расстояние между OIT и Oldest Snapshot Transaction (а не OAT) становится больше sweep interval (см. разд. "Другие переключатели gstat" главы 18). В Firebird 2.0 срабатывание sweep будет зависеть именно от разницы OAT-OIT. - Прим. науч. ред.

OST - это на самом деле номер транзакции, которая была активной на момент старта OAT. - Прим. науч. ред.

Возможно, здесь имеются в виду внешние ключи с опцией ON UPDATE/DELETE CASCADE. В этом случае при изменении мастер-записи автоматически модифицируются записи-детали. Ни в каких других случаях "зависимые" таблицы не обновляются сервером. - Прим. науч. ред.

Ничто не запрещает завершить транзакцию по COMMIT, независимо от успеха или неуспеха выполнения в ней операторов. Разумеется, именно в обработчиках исключений вызывать COMMIT действительно не рекомендуется. - Прим. науч. ред.