Firebird. Руководство разработчика баз данных - [4]
. ! .
Версии 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) является копией базы данных реального времени с некоторыми дополнительными атрибутами, которые делают ее недоступной для чтения, пока она не будет сделана доступной сервером в качестве базы данных. Оперативные копии могут переключаться либо вручную, либо автоматически. Назначение оперативного копирования - сделать базу данных доступной в кратчайший срок при поломках диска.
Java Enterprise Edition (Java EE) остается одной из ведущих технологий и платформ на основе Java. Данная книга представляет собой логичное пошаговое руководство, в котором подробно описаны многие спецификации и эталонные реализации Java EE 7. Работа с ними продемонстрирована на практических примерах. В этом фундаментальном издании также используется новейшая версия инструмента GlassFish, предназначенного для развертывания и администрирования примеров кода. Книга написана ведущим специалистом по обработке запросов на спецификацию Java EE, членом наблюдательного совета организации Java Community Process (JCP)
Разработчику часто требуется много сторонних инструментов, чтобы создавать и поддерживать проект. Система Git — один из таких инструментов и используется для контроля промежуточных версий вашего приложения, позволяя вам исправлять ошибки, откатывать к старой версии, разрабатывать проект в команде и сливать его потом. В книге вы узнаете об основах работы с Git: установка, ключевые команды, gitHub и многое другое.В книге рассматриваются следующие темы:основы Git;ветвление в Git;Git на сервере;распределённый Git;GitHub;инструменты Git;настройка Git;Git и другие системы контроля версий.
Когда приходится инкапсулировать, то иногда лучше меньше, чем большеЯ начну со следующего утверждения: Если вы пишете функцию, которая может быть выполнена или как метод класса, или быть внешней по отношению к классу, Вы должны предпочесть ее реализацию без использования метода. Такое решение увеличивает инкапсуляцию класса. Когда Вы думаете об использовании инкапсуляции, Вы должны думать том, чтобы не использовать методы.Удивлены? Читайте дальше.
В книге рассказывается история главного героя, который сталкивается с различными проблемами и препятствиями на протяжении всего своего путешествия. По пути он встречает множество второстепенных персонажей, которые играют важные роли в истории. Благодаря опыту главного героя книга исследует такие темы, как любовь, потеря, надежда и стойкость. По мере того, как главный герой преодолевает свои трудности, он усваивает ценные уроки жизни и растет как личность.
Embedded system software. General requirements for development and documentationСтандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени.
«Как пасти котов» – это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды разработчиков. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач.