Хранение хорошо организованных множеств скриптов, которые точно отражают самое последнее состояние ваших метаданных, является полезной практикой, которая прекрасно удовлетворяет большинству надежных высококачественных систем. Очень рекомендуется использовать в скриптах подробные комментарии при архивировании всех версий скриптов в версии управляющей системы.
Наиболее очевидная цель такой практики - "возврат к последней точке" при восстановлении после сбоев. Если беда идет за бедой - база данных разрушена, а резервные копии потеряны - метаданные можно восстановить из скриптов. Сохранившиеся данные из другой невосстанавливаемой базы данных могут быть восстановлены специалистами и помещены в базу данных.
Скорее всего, несколько разработчиков будут создавать базу данных в течение ее жизненного цикла. Известно, что разработчики ненавидят написание системной документации! Хранение аннотированных записей скриптов о каждом изменении базы данных- включая те, которые использовались интерактивно через isql или инструмент сторонних разработчиков, - это безболезненное и безопасное решение, которое работает во всех случаях.
Некоторые инструменты администратора для Firebird, включая isql, могут выделять метаданные из базы данных и сохранять их в виде файла скрипта. Об использовании isql см. разд. "Извлечение метаданных" главы 37. Так как извлечение метаданных является удобным помощником в вашем использовании скриптов, существует множество причин трактовать эти инструменты как "ассистенты" и взять себе за правило вручную поддерживать ваши главные скрипты схемы.
* 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 (тестовые данные) |