Версии Firebird
Двоичные файлы Firebird версии 1.0.x были разработаны для корректировки и улучшения написанных на языке С модулей, которые сообщество открытых исходных текстов наследовало от InterBase 6.0. Для Firebird 1.5 модули были полностью переписаны на C++ с высокой степенью стандартизации.
Переход от версии 1 к версии 1.5 был в большей мере внутренним, интерфейс прикладного программирования (Application Programming Interface, API) не изменился. Программное обеспечение приложений, написанное для версии 1, требует небольших (или вообще никаких) изменений для работы с версией 1.5.
И хотя рекомендуется установить и использовать самую последнюю версию, несовместимость операционных систем означает (при всем уважении к Linux), что последняя версия 1.0.x- единственный выбор для некоторых сайтов. Многие новшества версии 1.5 были привнесены в версию 1.0.x, и регулярно выпускаются дополнительные сборки.
Доступ к сети
Сервер Firebird, запущенный на любой платформе, принимает TCP/IP-подключения клиентов с любой клиентской платформы, которая может выполнять Firebird API.
Клиенты не могут подключиться к серверу Firebird через какую-нибудь файловую систему коллективного доступа (NFS, соединение клиентов Samba, общие ресурсы Windows или сетевой диск и т.д.).
Клиент должен подключаться с указанием абсолютного физического пути. Тем не менее в Firebird 1.5 и выше средство алиасов баз данных позволяет приложениям выполнять "мягкое подключение" с использованием именованных алиасов, чьи абсолютные пути указаны специально для каждого сервера.
К серверу Firebird, запущенному на хосте в Windows с сервисами, можно получить доступ от клиентов Windows с помощью сетевого протокола Named Pipes (именованные каналы).
Многоверсионная архитектура
Модель изоляции и управления работой множества пользователей, принятая в Firebird, является центральной частью архитектуры; она позволяет сохранять в базе данных более одной версии записи одновременно. Множество версий одной записи может существовать одновременно - отсюда термин "многоверсионный". Каждая пользовательская задача имеет свой собственный контекстный вид состояния базы данных (см. следующий раздел) и записывает свои версии записей на диск сервера. В этот момент новая версия записи (или удаленная запись) недоступна другим задачам пользователей.
Только самая последняя подтвержденная версия записи является видимой за пределами пользовательской задачи, которая успешно сохранила новую версию, и эта запись продолжает оставаться видимой для других задач. Другие задачи будут в курсе того, что что-то произошло с этой записью, поскольку они будут блокированы от изменения или удаления этой записи, пока новая версия не станет "официальной" после подтверждения изменений.
По причине использования многоверсионной архитектуры (называемой также MGA - Multi-generational architecture) для Firebird нет необходимости в двухфазной блокировке, используемой другими СУБД для управления многопользовательской работой.
Транзакции
Все задачи пользователей в Firebird помещаются внутрь транзакций. Задача начинается с оператора START TRANSACTION и завершается, когда выполненная работа подтверждается (commit) или отменяется (rollback). Задача пользователя может выполнять множество запросов к операциям в одной транзакции, включая операции с более чем одной базой данных.
Работа сохраняется в базе данных в два этапа. На первом этапе изменения сохраняются на диске без изменения состояния базы данных. На втором этапе изменения подтверждаются или отменяются клиентским процессом. В версии 1.5 и выше клиенты могут отменить часть работы, маркируя этапы с помощью точек сохранения (savepoints) и отменяя изменения до точки сохранения без отмены всей транзакции.
Транзакции в Firebird являются атомарными в том смысле, что вся работа в рамках транзакции будет сохранена или вся отменена.
Транзакции можно конфигурировать с использованием трех уровней изоляции и множества стратегий тонкой настройки параллельности выполнения и условий чтения/записи.
Хранимые процедуры и триггеры
Firebird имеет богатый язык процедурных расширений, PSQL, для написания хранимых процедур и триггеров. Это структурированный язык с поддержкой циклов FOR для множеств, условными переходами, обработкой ошибок и пересылкой событий. После создания код PSQL компилируется и сохраняется в двоичном виде.
Триггеры имеют сильную поддержку с фазами До (Before) и После (After) каждого события манипулирования данными. Для каждой фазы/события может существовать множество триггеров, они могут содержать номера, задающие последовательность выполнения. Firebird 1.5 и выше поддерживает триггеры Before и After, которые обрабатывают все три события манипулирования данными с условными переходами для каждого события.
Ссылочная целостность
Firebird имеет полную поддержку формальной, основанной на стандартах SQL, ссылочной целостности - иногда называемой декларативной ссылочной целостностью - включая необязательные каскадные изменения и удаления.
Оперативное копирование базы данных
Серверы Firebird могут при необходимости поддерживать создание оперативных копий базы данных. Оперативная копия (shadow) является копией базы данных реального времени с некоторыми дополнительными атрибутами, которые делают ее недоступной для чтения, пока она не будет сделана доступной сервером в качестве базы данных. Оперативные копии могут переключаться либо вручную, либо автоматически. Назначение оперативного копирования - сделать базу данных доступной в кратчайший срок при поломках диска.
Оперативное копирование не является репликацией.
Безопасность
Безопасность сервера
Firebird обеспечивает безопасность доступа пользователей к серверу с помощью идентификатора пользователя и зашифрованного пароля. Как и любой другой сервер базы данных, Firebird использует соответствующие средства защиты физического, сетевого доступа и файловой системы. Firebird может хранить зашифрованные данные, но за исключением шифрования пароля он не предоставляет средств шифрования самих данных.
! ! !
ВНИМАНИЕ! Поскольку встраиваемый сервер (см. разд. "Встраиваемый сервер") разработан для однопользовательских, автономных приложений, он совершенно не проверяет безопасность для хоста. Привилегии SQL, заданные на уровне базы данных, еще применяются, но приложение через встраиваемый сервер может получить доступ к любой базе данных на этом компьютере без указания пароля. (См. главу 34.)
. ! .
Привилегии SQL
Хотя пользователь должен быть авторизован для доступа к серверу Firebird, но никакой пользователь, за исключением SYSDBA и владельца базы данных, не имеет автоматически никаких прав на индивидуальную базу данных. Безопасность на уровне базы данных поддерживается посредством привилегий SQL. Пользователям должны быть явно предоставлены привилегии к любому объекту.
Роли SQL позволяют объединить несколько привилегий в группу и предоставить как "пакет" индивидуальным пользователям. Отдельный пользователь может иметь привилегии от нескольких ролей, хотя только одна роль может быть выбрана при соединении с базой данных.
Рабочие режимы
Сервер Firebird может быть инсталлирован для выполнения в одном из трех рабочих режимов (operating modes): Суперсервер (Superserver), Классический сервер (Classic server) и Встраиваемый сервер (Embedded server). Различие между ними- скорее вопрос архитектуры. Любое клиентское приложение, написанное для соединения с Суперсервером, может соединяться точно тем же способом и с Классическим сервером и выполнять в точности те же задачи. Обратное также верно, за исключением того, что у Суперсервера более высокие требования к безопасности потоков для модулей внешних функций (определенные пользователем функции, библиотеки наборов символов, BLOB-фильтры).
Встраиваемый сервер является вариантом Суперсервера.
Классический сервер
Классический сервер предшествует Суперсерверу исторически. Он был разработан после 1980 года, когда ресурсы машин были скромными, и программы использовали их весьма экономно. Модель Классического сервера являлась продолжением операционных систем, чьи возможности по использованию потоков либо не существовали, либо были слишком ограничены для поддержания Суперсервера. Классический сервер остается лучшим вариантом для условий, где важна высокая производительность и использование системных ресурсов увеличивается линейно при добавлении каждого нового соединения.
Поскольку Классический сервер может использовать множество центральных процессоров, он является весьма подходящим для сайтов, требующих выполнения множества продолжающихся в реальном режиме времени приложений, использующих автоматически полученные коллекции данных, с минимальным или вовсе отсутствующим интерактивным вводом.
! ! !
ПРИМЕЧАНИЕ. Классический сервер для Windows недоступен в версиях Firebird, предшествующих 1.5.
. ! .
Суперсервер
В 1996 году в предшественнике Firebird, InterBase 4.1 появился многопоточный Суперсервер для новых тогда 32-битных платформ Windows. Он позволял лучше использовать новые возможности серверов и компьютерных сетей. Возможности Суперсервера исключить взаимоблокировку поточных процессов и динамически выделять кэш-память сделали его более удобным, чем Классический сервер, когда велико количество пользователей, выполняющих чтение/запись, а системные ресурсы ограничены.
С бурным ростом операционных систем GNU/Linux на базе Intel к концу 1990-x годов Суперсервер стал хорошим решением для некоторых платформ POSIX. Основная структура Суперсервера для Linux была реализована в InterBase бета-версии 6.0 с открытыми исходными кодами и затем была полностью реализована в Firebird 1.0. Архитектура Суперсервера стала доступной для платформ Sun Solaris.
Встраиваемый сервер
Firebird 1.5 представил встроенный вариант Суперсервера для платформ Windows. В этой модели Суперсервер компилируется вместе с встроенным клиентом, который напрямую подключается к базе данных. Одна динамическая библиотека (fbembed.dll) использует межпроцессное коммуникационное пространство Windows для передачи клиентских запросов и ответов сервера. Его API идентичен API обычного Суперсервера или Классического сервера. В коде приложения не требуется ничего специального для использования встраиваемого сервера.
Приложение, использующее встраиваемый сервер, может применять только локальный метод доступа (см. главу 2) и поддерживает один и только один клиентский процесс. Вы можете использовать столько встроенных приложений на одной машине, сколько вам нужно, однако одна база данных может в каждый момент времени быть открыта только одним таким приложением. Приложение встраиваемого сервера может выполняться на той же машине одновременно с обычным сервером Firebird. Тем не менее с базой данных не может быть одновременно соединен обычный сервер и встраиваемый сервер.
Встраиваемый сервер удовлетворяет самым низким требованиям масштабируемости сервера Firebird, давая возможность распространять одно высокопродуктивное приложение для одной базы данных с минимальными затратами. Поскольку к базе данных может иметь доступ и обычный сервер, выполняющий репликацию при неработающем встроенном приложении, встраиваемый сервер особенно подходит для "компактных" установок - например, на ноутбук или даже на флэш-диск.
Сравнение моделей Суперсервера и Классического сервера см. в главе 36. В той же главе в разд. "Работа со встроенным сервером" вы найдете полное описание работы со встроенным сервером под Windows.
Пример базы данных
Везде в этой книге языковые примеры используют пример базы данных, которая находится в каталоге Examples в папке, где установлен Firebird. В дистрибутиве Firebird 1.0.x она называлась employee.gdb. В Firebird 1.5 это employee.fdb.
Краткое описание примера базы данных содержится в приложении 6.
Соглашения по документации
Основной текст книги представлен этим шрифтом.
Тексты, набранные данным шрифтом, являются кодом, скриптами или примерами командной строки.
! ! !
ПРИМЕЧАНИЕ. Фрагменты текста, выделенные как этот, - используются для того, чтобы привлечь ваше внимание к важным моментам, которые могут повлиять на ваше решение по использованию обсуждаемой возможности Firebird.
. ! .
! ! !
СОВЕТ. Фрагменты, выделенные как этот, содержат советы, блестящие идеи или рекомендации.
. ! .
! ! !
ВНИМАНИЕ! Обратите особое внимание на такой фрагмент.
. ! .
От изготовителя fb2.
I. К сожалению, выполнить вышеприведенные соглашения, в полном объеме, при изготовлении, варианта книги в формате fb2, не удалось.
II. Давайте, протестируем вашу читалку.
E=mc
Если предыдущую строку вы видите в таком виде:
E=mc2
Значит, ваша читалка не поддерживает надстрочные символы (к сожалению, [пока] это бывает очень часто).
Для такого случая, в данном файле, я применяю следующие соглашения:
Пример надстрочных символов:
Теорема Ферма x(^n^) + y(^n^) = z(^n^)
Согласен, непривычно, неудобно, некрасиво…, но я выбрал такое оформление для удобства "везунчиков".
Т.е. если ваша читалка показывает все правильно, легким движением вы превратите книгу в удобНОваримую.
Порядок действий (алгоритм):
1. Распаковать данный файл(если это архив).
2. Открыть файл подходящим текстовым редактором (не сочтите за рекламу, я пользуюсь Notepad++)
3. Произведите 2 операции замены
"(^" на "<sup>"
"^)" на "</sup>"
(как вы догадываетесь, в запросе надо будет нажать кнопку "Заменить все")
4. Сохраните файл, если хочется, сожмите в архив.
И будет вам счастье.
Ну, а нам, всем остальным, придется мучаться с тем, что есть…
III. Теперь, таблицы.
1 строка первого столбца | 2 строка первого столбца | 3 строка первого столбца |
1 строка второго столбца | 2 строка второго столбца | спорю, что не догадаетесь, какая это строка |
Если вместо симпатичной таблицы вы увидели такое:
1 строка первого столбца
2 строка первого столбца
3 строка первого столбца
1 строка второго столбца
2 строка второго столбца
...
Значит ваша читалка таблиц не видит, что очень жаль, т.к. в книге их 197.
Что делать?... Ну, я поступаю так. В Mozilla Firefox поставил плагин для чтения fb2, и все вышесказанные проблемы решены, конечно, возможны и другие варианты...
IV. Еще одно огорчение:
примеры кода в книге приведены без отступов. Т.е. примеры читаются очень плохо. Виноват в этом формат fb2, не отрабатываются отступы (или я чего-то не знаю :( ).
Вот и все.
Успехов w_cat.
Синтаксические шаблоны
Некоторые фрагменты кода представляют синтаксические шаблоны (syntax patterns), то есть модели кода, которые демонстрируют обязательные и необязательные элементы синтаксиса операторов SQL или команд командной строки.
Для синтаксических шаблонов применяются определенные соглашения по используемым символам. Для иллюстрации этих соглашений возьмем из главы 20 пример, показывающий синтаксический шаблон для оператора SQL SELECT:
SELECT
[FIRST (m) ] [SKIP (n) ] [[ALL] | DISTINCT]
<список-столбцов> [, [ими столбца] | выражение | константа ]
AS имя-алиаса
FROM <таблица-или-процедура-или-просмотр>
[{[INNER] | [{LEFT | RIGHT | FULL} [OUTER]] JOIN}]
<таблица -или-процедура -или-просмотр>
ON <условия-соединения> [{JOIN..}]
[WHERE <условия-поиска>]
[GROUP BY <список-группируемых столбцов>]
[HAVING <условие-поиска>]
[OTIION <выражение-выбора> [ALL] ]
[PLAN <выражение-плана>]
[ORDER BY <список-столбцов>]
[FOR UPDATE [OF столбец1 [, столбец2. .]] [WITH LOCK]]
Специальные символы
Элементы (ключевые слова, параметры), которые обязательны во всех случаях, появляются без каких-либо дополнительных пометок, они выделены таким шрифтом, как и весь код в книге. В предыдущем примере ключевые слова SELECT и FROM являются обязательными для каждого оператора SELECT.
Некоторые символы, которые никогда не появляются в операторах SQL или в командах командной строки, используются в синтаксических шаблонах для указания особых правил по их использованию. Это символы [],{}, |, <строка> и ... (многоточие). Они используются в шаблонах следующим образом.
Квадратные скобки [ ] указывают, что элемент(n) в скобках являются необязательными. Когда встречаются вложенные квадратные скобки, то вложенные или внешние элементы являются необязательными.
Фигурные скобки { } указывают, что элементы внутри скобок являются обязательными. Обычное использование фигурных скобок - это представление необязательного элемента (заключенного в квадратные скобки), означающее: "Если необязательный элемент используется, часть, заключенная в фигурные скобки, является обязательной". В предыдущем примере, если используется необязательная явная фраза
JOIN,
[{[INNER] | [{LEFT | RIGHT | FULL} [OUTER]] JOIN}]
то внешняя пара фигурных скобок указывает, что ключевое слово JOIN является обязательным. Внутренняя пара фигурных скобок означает, что если задано соединение OUTER, то оно должно быть определено как LEFT, RIGHT или FULL С необязательным использованием ключевого слова OUTER.
Символ вертикальной черты | используется для разделения взаимоисключающих элементов. В предыдущем примере LEFT, RIGHT и FULL являются взаимоисключающими, также внутреннее (INNER) и внешнее (OUTER) соединения являются взаимоисключающими.
Параметры задаются строкой, которая заключается в угловые скобки < >. Например, [WHERE <условия-поиска>] указывает, что одно или более условий поиска требуется в качестве параметров для необязательного предложения WHERE В синтаксисе оператора SELECT.
В некоторых случаях <строка> может быть сокращением для более сложной конструкции, которая в последующих строках синтаксического шаблона будет раскрываться уровень за уровнем для получения полной детализации. Например, вы можете увидеть приблизительно следующее выражение: