Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

45

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

46

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

47

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

48

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

49

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

50

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

51

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

52

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

53

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

54

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

55

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

56

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

57

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

58

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

59

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

60

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

61

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

62

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

63

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

64

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

65

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

66

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

67

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

68

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

69

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

70

FIRST и SKIP всего лишь ограничивают количество записей, выдаваемых клиенту. Запрос вне зависимости от наличия или отсутствия FIRST и SKIP всегда будет выполнен целиком. - Прим. науч. ред.

71

Если два набора, объединяемых UNION, принципиально не будут содержать дубликатов строк, необходимо использовать UNION ALL, чтобы сервер не занимался зря работой по удалению несуществующих дубликатов строк. - Прим. науч. ред.

72

Это "ускоренное" вычисление логических значений, которое реализовано в Firebird 1.5 и выше. Firebird l.Ojc использует полное логическое вычисление. Для тех, кто любит изобретательные загадочные выражения, старый метод может быть восстановлен при использовании параметра конфигурации FullBooleanEvaluation.

73

Операторы сравнения Firebird поддерживают сравнение значения левой части с результатом скалярного подзапроса (встроенного запроса) в правой части оператора. Подробности см. в разд. "Запросы существования" позже в этой главе и в обсуждении подзапросов в следующей главе.

74

Для русского языка обычно используется кодировка WIN 1251, и два варианта COLLATE - WIN 1251 (по умолчанию), и PXWCYRL. За особенностями использования вариантов COLLATE, и кодировками и сортировками для других языков (в том числе стран СНГ) обратитесь к ReleaseNotes. - Прим. науч. ред.

75

Firebird 1.0.x выполняет полные логические вычисления. Сокращенное вычисление булевых выражений в более поздних версиях может быть отключено на уровне сервера при установке параметра конфигурации CompieteBooleanEvaluation. Подробности см. в главе 3.

76

До Firebird 1.5 функция UPPER работала только для столбцов COLLATE PXW_CYRL (или при явном указании для конкретного столбца). В Firebird 1.5 таблица перекодировки символов в верхний регистр есть и в "умолчательном" COLLATE WIN1251. - Прим. науч. ред.

77

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

78

Ключевое слово OUTER для всех случаев является необязательным. -

79

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

80

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