Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Название:Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2006
- Город:Санкт-Петербург
- ISBN:5-94157-609-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ краткое содержание
Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.
Для разработчиков баз данных
Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
"Точки сохранения" в PSQL
Добавление возможностей создания пользовательских точек сохранения в Firebird 1.5 позволяет приложению управлять область действия отката транзакции. В PSQL всегда была возможность обработки исключений. Подробности см. в главе 32.
Советы по оптимизации поведения транзакции
Выбор подходящей модели транзакции
Модель "одна транзакция на все приложение" искушает неопытного разработчика игнорировать проблему многопользовательской работы в пользу "простоты программирования". Результатом является такая архитектура приложения, которая плохо работает на всех уровнях: медленные запросы и ответы на обновление списков, перегруженная сеть, не дружественная к пользователю последовательность выполняемых действий и высокий уровень конфликтов.
Не переходите к "общему" пока вам это не понадобилось
Общие интерфейсы приложений для баз данных, такие как ODBC или Borland BDE, объединяют одно соединение с базой данных с одной транзакцией. Поскольку их задачей является скрыть разницу между простенькими, основанными на файлах ре- позиториями данных и сложными, использующими транзакции системами управления базами данных, они не поддерживают возможностей наличия множества активных конкурирующих транзакций в сессии базы данных или транзакций, имеющих доступ к нескольким базам данных.
В лучшем случае эти общие интерфейсы обеспечивают примитивный способ масштабирования простых баз данных или выравнивания разницы между различными реализациями СУБД всевозможных разработчиков. Если вам не нужен такой низкоуровневый общий знаменатель, не используйте их.
Использование возможностей множества транзакций
Клиент Firebird может запустить множество параллельных транзакций. Пользовательская работа с множеством задач в одном приложении может выполнять различные действия с теми же самыми (или перекрывающимися) наборами данных. Модель транзакций Firebird обеспечивает большие преимущества в проектировании, где нужно удовлетворять требованиям модульности в многозадачном окружении в очень чувствительной манере. Важной задачей при создании программного обеспечения являются техники разработки, обеспечивающие сохранение процесса работы и синхронизированного вида состояния базы данных для пользователя.
Сохраняйте передвижение OAT!
Медленное передвижение OAT почти всегда указывает на транзакции, выполняющиеся долго. Исключение таких транзакций является одним из наилучших навыков, которые вы можете получить, обучаясь написанию клиентских приложений для Firebird.
Проще всего обвинить поведение пользователей в появлении долгих транзакций. Вы должны помочь им научиться завершать задачи в разумное время: не отправляться пить кофе, не завершив задач, не выдавать "диких запросов" в пиковое время и т.д. При этом хорошее проектирование клиентского приложения исключает его зависимость от правильного поведения пользователя.
* Подходят механизмы, которые завершают со временем забытые транзакции.
* Как основное правило, исключите интерфейсы просмотра данных и используйте практичные средства.
* Если использование интерфейса просмотра неизбежно, изолируйте операторы, выбирающие данные для просмотра, в транзакциях READ-ONLY READ COMMITTED.
* Убедитесь, что транзакции READ/WRITE регулярно подтверждаются - даже если пользователи используют их только для просмотра данных.
* Избегайте приложений, выполняющих произвольные запросы, включая в запросы WHERE и устанавливая ограничения по времени.
* Убедитесь, что ваши приложения имеют средства для периодического выполнения "жестких подтверждений" любых транзакций, выполняющих COMMIT RETAIN.
* Возьмите за правило использовать RollbackRetaining не более одного раза в обработчике исключений. Не помещайте RollbackRetaining внутрь циклов!
* Учитывайте, что происходит с транзакциями в сервере! Используйте gstat -h или эквивалентный инструмент для отслеживания OIT и OAT. Обращайте внимание на "зазор" [109] Инструмент IBAnalyst (см. www.ibase.ru) выдаст все возможные предупреждения и рекомендации по поводу состояния транзакций на сервере. - Прим. науч. ред.
.
* Не пренебрегайте наведением порядка в базе данных. Чистка (sweep) должна выполняться систематически. Регулярное выполнение резервного копирования, даже без восстановления базы данных, поможет поддерживать инвентарные страницы транзакций в хорошей форме [110] Выполнение backup никак не влияет на Transaction Inventory Page, a sweep может продвинуть вперед OIT, но не более того. - Прим. науч. ред.
.
Теперь, когда вы освоили запутанные вопросы управления транзакциями, самое время направить ваши таланты на программирование на серверной стороне. В части VII вы начнете работать с мощными средствами, доступными в PSQL: хранимые процедуры и триггеры, обработка пользовательских исключений, механизм событий в Firebird. В главе 28 мы начнем рассматривать преимущества действий на стороне сервера для централизации бизнес-правил и сокращения сетевого трафика перед тем, как перейдем к синтаксису и техникам в следующих главах.
ЧАСТЬ VII. Программирование на сервере.
ГЛАВА 28. Введение в программирование в Firebird.
Одним из самых больших преимуществ полнокровных реализаций реляционных баз данных SQL является их способность компилировать и выполнять внутренние модули (хранимые процедуры и триггеры), представленные разработчиками в виде исходных кодов. Язык, который предоставляет такую возможность для сервера Firebird - PSQL - простой, но мощный набор расширений языка SQL, который объединяется с обычными операторами языка манипулирования данными (DML) для создания компилируемых исходных модулей.
Обзор модулей сервера
Языком высокого уровня для программирования в Firebird на стороне сервера является SQL. Исходный код предоставляется серверу в форме расширений языка программирования SQL- операторов и конструктов PSQL- и операторов DML. Сами эти операторы находятся внутри одного оператора DDL вида:
{CREATE | RECREATE | ALTER} {TRIGGER | PROCEDURE} <���имя> . . .
. . .
AS
. . .
BEGIN
<���один или более блоков операторов>
END
Синтаксис написания модулей PSQL подробно рассматривается в следующих главах.
Назначением каждого из этих "супероператоров DDL" является создание и сохранение одного исполняемого модуля (хранимой процедуры или триггера) или переопределение (RECREATE или ALTER) существующего объекта. Оператор DDL также используется для уничтожения (DROP) исполняемых объектов.
PSQL поддерживает три оператора манипулирования данными: INSERT, UPDATE и DELETE и возможность выборки (SELECT) одной строки или многострочных наборов элементов данных с помещением в локальные переменные. Расширения PSQL обеспечивают перечисленную далее языковую и логическую поддержку.
Читать дальшеИнтервал:
Закладка: