Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

или

CONNECT 'd:\databases\MyDatabase.gdb' USER 'SYSDBA' PASSWORD 'masterkey';

Операторы в скриптах DDL могут подтверждаться одним или несколькими способами:

* включением в соответствующих местах скрипта операторов COMMIT, чтобы гарантировать доступность новых объектов базы данных всем последующим зависящим от них операторам;

* включением в начало скрипта следующего оператора:

SET AUTODDL ON;

Для отмены автоматического подтверждения операторов DDL в скрипте isql используйте:

SET AUTODDL OFF;

Ключевые слова ON и OFF необязательны. Сокращение SET AUTO может быть использовано в качестве двухстороннего переключателя. Для большей ясности рекомендуется использовать SET AUTODDL с явным указанием ключевых слов ON и OFF.

Если вы выполняете свой скрипт в isql, то изменения базы данных операторами определения данных (DDL)- например, операторами CREATE и ALTER- автоматически подтверждаются по умолчанию. Это означает, что другие пользователи базы данных видят изменения сразу после выполнения оператора DDL.

Некоторые инструменты обработки скриптов намеренно отключают такое поведение автоматического подтверждения, потому что оно может усложнить отладку. Убедитесь, что вы понимаете поведение того инструмента сторонних разработчиков, который вы используете для обработки скриптов.

Изменения базы данных, выполненные операторами манипулирования данными (DML) - INSERT, UPDATE и DELETE, - не станут постоянными, пока не будут подтверждены. Явно включите операторы COMMIT в ваш скрипт для подтверждения изменений DML.

Для отмены всех изменений базы данных после последнего COMMIT используйте ROLLBACK. Подтвержденные изменения не могут быть отменены.

Скрипты DDL могут быть выполнены в сессии интерактивного isql с использованием команды INPUT, как было описано ранее. Многие инструменты сторонних разработчиков позволяют выполнять и даже интеллектуально отлаживать скрипты в среде графического интерфейса.

Хранение хорошо организованных множеств скриптов, которые точно отражают самое последнее состояние ваших метаданных, является полезной практикой, которая прекрасно удовлетворяет большинству надежных высококачественных систем. Очень рекомендуется использовать в скриптах подробные комментарии при архивировании всех версий скриптов в версии управляющей системы.

Наиболее очевидная цель такой практики - "возврат к последней точке" при восстановлении после сбоев. Если беда идет за бедой - база данных разрушена, а резервные копии потеряны - метаданные можно восстановить из скриптов. Сохранившиеся данные из другой невосстанавливаемой базы данных могут быть восстановлены специалистами и помещены в базу данных.

Скорее всего, несколько разработчиков будут создавать базу данных в течение ее жизненного цикла. Известно, что разработчики ненавидят написание системной документации! Хранение аннотированных записей скриптов о каждом изменении базы данных- включая те, которые использовались интерактивно через isql или инструмент сторонних разработчиков, - это безболезненное и безопасное решение, которое работает во всех случаях.

Некоторые инструменты администратора для Firebird, включая isql, могут выделять метаданные из базы данных и сохранять их в виде файла скрипта. Об использовании isql см. разд. "Извлечение метаданных" главы 37. Так как извлечение метаданных является удобным помощником в вашем использовании скриптов, существует множество причин трактовать эти инструменты как "ассистенты" и взять себе за правило вручную поддерживать ваши главные скрипты схемы.

* Firebird не хранит комментарии при сохранении определений метаданных. Многие системные таблицы имеют столбец BLOB, обычно называемый RDB$DESCRIPTION, в котором может сохраняться в виде единого целого часть предоставленного пользователем описания. При извлечении метаданных инструментом isql этот столбец не выводится, хотя некоторые инструменты сторонних разработчиков его поддерживают.

* Все инструменты извлечения метаданных генерируют только текущие метаданные. Не существует истории изменений - даты, причины или авторы изменений.

* Некоторые инструменты, включая isql, генерируют метаданные в неверной последовательности с точки зрения зависимостей, делая скрипты невозможными в использовании для перегенерации базы данных без их корректировки. Подобная задача может быть утомительной или даже невозможной в зависимости от того, насколько выполняющий ее человек хорошо знает метаданные.

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

Автор жестко пропагандирует поддержку полностью аннотированных скриптов схемы вручную и разделение их на несколько отдельных файлов. Пример набора скриптов в табл. 14.2 описывает и регенерирует базу данных с именем leisurestore.fdb.

Таблица 14.2. Пример набора скриптов для схемы

Устойчивый набор скриптов может быть соединен вместе в цепочку с использованием оператора isql INPUT В качестве последнего оператора в предыдущем скрипте. Например, для присоединения скрипта leisurestore_0.sql к leisurestore_01.sql завершите скрипт следующим образом: