В версии 1.0.x нужно будет Сконфигурировать параметр external_function_directory в iscconfig/ibconfig для каждой платформы, на которой эти функции будут использоваться, поскольку эта версия не содержит "пути по умолчанию" для модулей функций. По умолчанию должен работать каталог /UDF, однако практика показывает, что это ненадежно без явно заданной конфигурации.

Для Firebird 1.5 и выше существуют другие режимы конфигурации (UDFAccess) для размещения библиотек функций (см. главу 36), включая RESTRICT, который позволяет задать для них один или более каталогов. Если вы используете RESTRICT, то в объявление нужно включить полный путь к модулю и расширение файла. В этом случае база данных не будет переносима на другую операционную систему, пока вы не удалите из базы данных функции и их зависимости.

Следующий пример показывает объявление функции с указанием полного пути:

DECLARE EXTERNAL FUNCTION lpad

CSTRING(80) , INTEGER, CSTRING(1)

RETURNS CSTRING(80) FREE_IT

ENTRY_POINT ' IB_UDF_lpad' MODULE_NAME '/opt/extlibs/ib_udf .so' ;

Приложение 1 содержит детальное описание с примерами внешних функций из библиотек ib_udf и fbudf из каталога /UDF каталога инсталляции Firebird, а также многие функции из FreeUDFLib.

Важность использования логики выражений для трансформации абстрактных данных в осмысленную информацию аналогична важности использования средств SQL по слиянию данных из множества таблиц в один набор связанных данных. В следующей главе мы рассмотрим существующие в DML способы выполнения таких многотабличных операций. Эта глава заканчивается специальной темой оптимизации запросов Firebird и использованием планов запросов (предложение PLAN) В запросах SELECT.

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

Firebird не поддерживает многотабличные запросы, которые находятся в нескольких базах данных. Тем не менее возможен запрос к нескольким таблицам одновременно из нескольких баз данных внутри одной транзакции, имеющей полное двухфазное завершение (two-phase commit- 2РС). Клиентские приложения могут сопоставлять данные и выполнять отдельные операторы манипулирования данными в пределах базы данных. Мультибазовые транзакции обсуждаются в части VI.

В этой главе мы рассмотрим три метода динамического поиска данных в нескольких таблицах [77] в контексте одного оператора и одной базы данных: соединения, подзапросы и объединения.

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

Три метода поиска данных во множестве таблиц довольно сильно отличаются друг от друга и, как правило, выполняют различные виды поисковых задач. Поскольку соединения и подзапросы используют слияние потоков данных из строк различных таблиц, их роли частично совпадают при некоторых условиях. Коррелированный подзапрос, который может создавать относительные связи между колонками главной таблицы, иногда может содержать спецификации для получения того же результата, что и соединение, без использования самого соединения. С другой стороны, объединения запросов не используют слияние потоков; напротив, они "собирают" строки. Их роль никогда не совпадает с ролью запросов соединения или подзапросов.

Соединения, подзапросы и объединения не являются взаимоисключающими, несмотря на то, что результат объединения не может быть соединен один с другим или с другими результатами. Спецификации соединения и объединения могут включать подзапросы, и некоторые подзапросы могут содержать соединения.

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

Операции соединения создают наборы данных только для чтения, для которых не могут применяться операции INSERT, UPDATE или DELETE. Интерфейс некоторых приложений содержит средства, позволяющие сделать поведение соединенных наборов данных таким, как если бы они были изменяемыми.

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