Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
! ! !
ПРИМЕЧАНИЕ. Не используйте алиасы в скриптах, которые создают базы данных.
. ! .
Пример:
SET SQL DIALECT 3 ;
CREATE DATABASE 'd:\databases\MyDatabase.fdb' PAGE_SIZE 8192
DEFAULT CHARACTER SET ISO8859_1 USER 'SYSDBA' PASSWORD 'masterkey';
или
CONNECT 'd:\databases\MyDatabase.gdb' USER 'SYSDBA' PASSWORD 'masterkey';
Операторы в скриптах DDL могут подтверждаться одним или несколькими способами:
* включением в соответствующих
* включением в начало скрипта следующего оператора:
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,
* Firebird не хранит комментарии при сохранении определений метаданных. Многие системные таблицы имеют столбец BLOB, обычно называемый RDB$DESCRIPTION, в котором может сохраняться в виде единого целого часть предоставленного пользователем описания. При извлечении метаданных инструментом isql этот столбец не выводится, хотя некоторые инструменты сторонних разработчиков его поддерживают.
* Все инструменты извлечения метаданных генерируют только текущие метаданные. Не существует истории изменений - даты, причины или авторы изменений.
* Некоторые инструменты, включая isql, генерируют метаданные в неверной последовательности с точки зрения зависимостей, делая скрипты невозможными в использовании для перегенерации базы данных без их корректировки. Подобная задача может быть утомительной или даже невозможной в зависимости от того, насколько выполняющий ее человек хорошо знает метаданные.
* Даже умеренно увеличивающаяся в размерах база данных может иметь огромное количество объектов, особенно когда проектирование системы приводит к интенсивному использованию модулей встроенного кода. Слишком большие скрипты часто завершаются с ошибками по причине различных ограничений в выполнении или в ресурсах. Большие, плохо организованные скрипты также сбивают с толку и раздражают при использовании их в качестве документации.
Автор жестко пропагандирует поддержку полностью аннотированных скриптов схемы вручную и разделение их на несколько отдельных файлов. Пример набора скриптов в табл. 14.2 описывает и регенерирует базу данных с именем leisurestore.fdb.
Таблица 14.2. Пример набора скриптов для схемы
Файл | Содержимое |
leisurestore_01 .sql | Оператор CREATE DATABASE; определения CREATE DOMAIN, CREATE GENERATOR и CREATE EXCEPTION |
leisurestore_02.sqi | Все операторы CREATE TABLE, включая ограничения UNIQUE; операторы ALTER TABLE добавляют все первичные ключи в виде именованных ограничений PRIMARY KEY |
leisurestore_03.sql | Операторы ALTER TABLE, добавляющие ограничения FOREIGN KEY |
leisurestore_04.sql | Операторы CREATE INDEX |
leisurestore_05.sql | Операторы CREATE TRIGGER |
leisurestore_06.sql | Операторы CREATE PROCEDURE |
leisurestore_07.sql | Скрипт операторов DML, который добавляет строки в статичные (управляющие) таблицы |
leisurestore_08.sql | Операторы GRANT (скрипт безопасности) |
leisurestore_09.sql | Более поздние изменения в корректной последовательности зависимостей |
leisurestore_10.sql | Скрипты QA (тестовые данные) |