А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Ограничение результатов выборки FIRST/SKIP
Как и в Firebird 1.0, результат выборки SELECT может быть ограничен с использованием инструкций FIRST/SKIP (В Borland InterBase начиная с версии 6.5 используется аналогичная по назначению конструкция ROWS.)
При значении аргумента FIRST, равном 0, результатом выборки будет пустое множество, в отличаие от Firebird 1.0, где будет возбуждено исключение с сообщением о неверном параметре.
Увеличение глубины рекурсии процедур и триггеров
Количество рекурсивных вызовов процедур и триггеров увеличено до 1000.
Использование переменной окружения ISC_PATH
В Yaffil расширены возможности использования переменной окружения ISC_PATH для задания префикса к пути базы данных. Переменная ISC_PATH используется, если в имени базы данных, указываемом клиентом, не содержит каталогов или имени сервера. Переменная ISC_PATH может использоваться как на клиенте, так и на сервере. Примеры:
* Использование ISC_PATH на сервере. Пусть базы данных на сервере находя 1ся в каталоге c:database. Определим переменную ISC_PATH=c:database. Далее можно использовать на клиентском компьютере строку соединения вида servemame:database.gdb для открытия базы данных c:databasedatabase.gdb.
* Использование ISC_PATH на клиенте. Пусть базы данных располагаются на сервере serxername в каталоге c:database. Определим на клиенте переменную ISC_PATH как servername:c:database. После этого клиент сможет обращаться к базам данных только по короткому имени файла БД, например CONNECT sales.gdb. Используем внешний файл в базе sales.gdb:
CREATE TABLE customers EXTERNAL FILE "sales_flies/customers.txt" ( ... );
Безопасная работа с внешними таблицами
Файлы внешних таблиц могут располагаться ТОЛЬКО в одном из каталогов, разрешенных конфигурационным параметром EXTERNAE_FIEE_DIRECTORY. а также в их подкаталогах
По умолчанию конфигурационный файл не содержит параметров EXTERNAL_FELE_DIRECTORY, поэтому использовать внешние файлы вообще не разрешается. Если нужно полностью снять ограничения на размещение внешних файлов, следует задать корневые каталоги дисков в EXTERNAL_FILE_DIRECTORY, например:
EXTERNAL_FILE_DIRECTORY "с:"
EXTERNAL_FILE_DIRECTORY "d:"
Таким образом, любой файл на диске становится доступным для доступа через внешние таблицы, что соответствует прежнему, небезопасном}' поведению InterBase pre-7 и Firebird 1.0. Из-за серьезных проблем с безопасностью НЕ РЕКОМЕНДУЕТСЯ использовать такие установки.
Каждому каталогу, сконфигурированному для использования в качестве хранилища внешних таблиц, может быть присвоено логическое имя.
Логическое имя каталога необязательно и задается вторым аргументом:
EXTERNAL_FILE_DIRECTORY "c:databasesfiles" myfiles
На логическое имя можно ссылаться при задании внешней таблицы. Для этого нужно указать логическое имя каталога после символа $ в начале имени внешнего файла. Например:
CREATE TABLE customers EXTERNAL FILE "$myflies/customers.txt" ( ... );
Другой способ задания внешних таблиц состоит в указании абсолютного пути к файлу. При этом файл также может располагаться только в разрешенных каталогах. Например,
CREATE TABLE customers EXTERNAL FILE
"с:/databases/files/customers.txt" (...) ;
И наконец, можно задавать файл внешней таблицы с указанием имени относительно каталога базы данных:
CREATE TABLE customers EXTERNAL FILE "files/customers.txt" ( ... );
При этом каталог, в котором находится файл, должен быть разрешен параметром EXTERN AL_FILE_DIRECTORY.
НЕ РЕКОМЕНДУЕТСЯ разрешать для размещения файлов внешних таблиц каталоги с базами данных, поскольку в этом случае пользователи получают доступ к файлам этих баз данных. Если есть желание разместить внешние таблицы рядом с базой данных, то следует создать подкаталог для внешних файлов для каждой базы данных и разрешить его в EXTERNAL_FELE_DIRECTORY. Допустим, все базы данных лежат в c:databases, среди которых sales.gdb. Создаем каталог sales_files, разрешаем его для использования:
EXTERNAL_FILE_DIRECTORY "с:databasessales_files"
Классическая архитектура на Windows NT (Yaffil CS)
Реализация классической архитектуры Yaffil CS на платформе Windows NT является значительным преимуществом сервера Yaffil по сравнению с другими вариантами InterBase/Firebird, существующими на сегодняшний день. Классическая ветвь InterBase для Windows NT прекратила развитие в 1994 году в связи с началом разработки варианта SuperServer для версии 4.0. Предполагалось, что SuperServer быстро заменит классическую архитектуру, однако реализация SuperServer, имеющая приемлемые характеристики при использовании с большой нагрузкой, не была удачной. В связи с этим до недавнего времени версии InterBase для платформ Solaris и Linux поставлялись в двух вариантах - SuperServer и Classic Server.
Классическая архитектора обладает следующими преимуществами:
* Равномерное распределение нагрузки между выполняющимися запросами на разных соединениях.
* Эффективное использование многопроцессорных систем (SMP).
* Более полное использование оперативной памяти.
* Встраиваемый (embedded или in-process) сервер.
Другими словами, сферой использования Classic Server являются высокопроизводительные системы, обслуживающие одновременно большое число подключений, в то время как SuperServer более эффективен на системах небольшого размера.
Не будем здесь останавливаться на отличиях архитектур Classic и SuperServer, подробно описанных выше в этой книге, рассмотрим лишь особенности реализации Yaffil Classic Server.
* В отличие от сервера Interbase 4.0 для Windows NT, Yaffil CS способен запускаться не только как служба Windows NT, но и как приложение. Во втором случае в области system tray панели задач Windows появляется красная иконка Yaffil Server. В строке версии вместо пары букв WI (платформа Windows Intel) используются буквы N1 (платформа NT Intel), поскольку именно так обозначала себя первая версия InterBase CS 4.0 для Windows NT.
* Количество соединений, поддерживаемых Yaffil Classic Server, ограничено только ресурсами системы, в основном оперативной памятью. Ограничение для InterBase CS 4.0 в 90-120 соединений при запуске сервиса ibremote с параметром "not allowed to interact with desktop" снято в Yaffil CS.
Встраиваемый сервер
Как известно, первые версии сервера InterBase, работающие под операционной системой UNIX и другими, более экзотическими ОС, использовали прямое связывание кода сервера с клиентским приложением. Строго говоря, термины клиент и сервер здесь не очень уместны, так как существует всего один процесс.
Можно провести аналогию с технологией COM (Component Object Model), в которой используется термин "in-process server" (сервер внутри процесса) для обозначения компоненте, загружаемых в адресное пространство клиентского приложения. Такой способ загрузки обеспечивает максимальную эффективность за счет отсутствия накладных расходов, связанных с упаковкой параметров вызова (marshalling), передачей упакованного блока данных в адресное пространство сервера с помощью некоторого транспортного механизма (сетевого протокола или буферов разделяемой памяти) и диспетчеризацией вызова обработчика запроса на серверной стороне.
Архитектура Yaffil Classic дает возможность приложениям использовать внутрипроцессный сервер Yaffil. Такое использование часто называют встраиваемым (embedded), подразумевая легковесность и упрощение тиражирования прикладных систем. По сравнению с традиционным сервером, внутрипроцессный Yaffil не требует запуска дополнительного процесса сервера или инсталляции служб NT. Приложению для работы требуется всего лишь одна библиотека динамической загрузки (DLL). Общий объем исполнимых модулей при этом также сокращается.
Однако встраиваемое использование подразумевает некоторые (возможно, значительные для вашего приложения) ограничения.
Встраиваемый сервер может использоваться только в однопоточных приложениях. Существующее ядро InterBase/Firebird/Yaffil не является безопасным для использования из нескольких потоков (thread-safe). Глобальные структуры данных сервера не защищены от одновременного изменения; кроме того, внутри ядра широко используется локальное состояние потока. Таким образом, поведение сервера будет непредсказуемым при вызове функций сервера с нескольких потоков одновременно, а также при использовании соединений, первоначально открытых в другом потоке.
Если вы разрабатываете программы, работающие в среде сервера приложений или Web-сервера, таких? как СОМ+ или IIS, то встраиваемый сервер для вас также непригоден, поскольку подобные среды используют собственное управление потоками.
Конфигурация безопасности для базы данных
При нахождении кода сервера в составе клиентского приложения необходим полный доступ к файлу базы данных. В то же время нельзя гарантировать разграничение доступа на основе разрешений SQL к объектам БД. Поскольку код приложения имеет физическую возможность обращаться к любой области базы данных, ограничения SQL являются всего лишь джентльменскими соглашениями.
С другой стороны между приложением и базой данных нет посредников, таких? как сетевые устройства и средства межпроцессного обмена данными. Поэтому нет необходимости использовать средства защиты данных при клиент - серверном взаимодействии.
