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

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

См. ограничение NOT NULL для столбца, NULL может оказаться несовместимым значением

Здесь мы говорим об архитектуре Intel. Выравнивание может отличаться в некоторых архитектурах.

Создание спецификаций для чтения/записи во внешний файл может потребовать гораздо больше детальных знаний о формате, чем здесь обсуждается. Наборы символов и размеры в байтах могут оказаться проблемой. Во многих случаях использование в качестве набора символов нейтрального набора символов OCTETS в определении внешней таблицы может решить некоторые проблемы. Импорт и экспорт данных не подчиняется принципу "один размер подходит всем".

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

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

Толковое добавление к этому в книге Data Modeling Essentials, 2nd Edition by Graeme Simsion (Coriolis, 2000).

Действие NO ACTION иногда называют "ограниченным" действием.

Не следует полагаться на триггерную ссылочную целостность потому, что ограничения PRIMARY KEY, FOREIGN KEY и UNIQUE работают вне контекста транзакций (т. е. "видят" все версии записей), а пользовательские триггеры - в контексте пользовательских транзакций. В результате пользовательский триггер, проверяющий наличие определенной записи, никоим образом не узнает, что эта запись на самом деле уже удалена или изменена в другой, конкурирующей, транзакции. -Прим. науч. ред.

И надеяться, что эта маленькая причуда оптимизатора с ключами один-к-одному будет разрешена в следующих релизах.

В случаях, когда условие поиска задает LIKE ' string% ', оптимизатор обычно преобразовывает его к предикату STARTING WITH 1 string1 и использует индекс, если он доступен.

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

В Firebird и InterBase индексы не могут быть "разбалансированы". -Прим. науч. ред.

На самом деле индексы в Firebird и Interbase никогда не бывают "разбалансированными", т. е. глубина индекса всегда постоянна для всех листовых страниц. Соответственно, перестраивать индекс имеет смысл, когда он поврежден и когда требуется высокая скорость массовых вставок, удалений или обновлений. В реальных и больших базах данных плотность заполнения страниц индекса не опускается ниже 85%, независимо от числа дубликатов ключей. - Прим. науч. ред.

Изложенное понятие селективности обратно числам, реально используемым оптимизатором. Оптимизатор берет информацию о селективности из столбца RDB$STMTSTICS таблицы RDB$INDICES, который вычисляется по формуле 1/(число ключей - число повторяющихся ключей). Чем меньше это число, тем выше селективность индекса и тем полезнее он с точки зрения оптимизатора. Для уникальных индексов селективность стремится к нулю (зависит от числа ключей). Для неуникальных индексов худшим случаем является селективность, равная 1, когда все значения ключей идентичны. - Прим. науч. ред.

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

В этом месте разговор идет со слов Ann Harrison, "матери InterBase".

Сборка мусора в больших цепочках дубликатов ключей значительно ускорена в Firebird 2.0. Собственно, в Firebird 2.0 изменена структура индексов. - Прим. науч. ред.

IBOConsole поддерживает Lorenzo Mengoni - см. http://www.mengoni.it.

Это неверно, и автор подтвердил ошибку. Next transaction не имеет никакой связи со sweep. Автоматический sweep стартует, когда разница между Oldest Snapshot и Oldest Interesting больше Sweep interval (в Firebird 2.0 за верхнюю границу берется не Oldest Snapshot, a Oldest Active). -Прим. науч. ред.

Американцы предпочитают говорить "сиквел". -Прим. перев.

Рекомендую обратиться на http://www.interbase-world.com. Там можно найти перевод на русский язык некоторых книг из документации фирмы Borland по InterBase 7.1. - Прим. пе-

В переводе на русский язык книга называется М. Грабер "SQL" и доступна в книжных магазинах начиная с 2001 г. - Прим. науч. ред.

Фактически синтаксис именованного курсора доступен как "скрытая возможность" и в PSQL, хотя он не полностью реализован в Firebird 1.5. Синтаксис был расширен после версии 1.5 и должен появиться в последующих релизах.

Более подробную информацию см. в Embedded SQL Guide (EmbedSQL.pdf) в документации по InterBase 6.0, опубликованной Borland.

Программисты прямого API и разработчики компонентов интерфейса могут получить больше информации из InterBase API Guide (APIGuide.pdf) в документации по InterBase 6.0, опубликованной Borland.

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

В InterBase 6.5 и выше вместо FIRST используется ключевое слово ROWS, следующее за ORDER BY. Этот же синтаксис может быть использован и в Firebird 2.0. Подробнее о синтаксисе ROWS см. В документации по InterBase 7.x - Прим. науч. ред.