В первой части был инструмент, который снимает схему Firebird и раскладывает её деревом файлов: один объект — один файл. Он отлично отвечает на вопрос «как эта процедура выглядит сейчас» и совершенно беспомощен в вопросе «кто её поменял в среду вечером». Дамп — это фотография, а нам нужен ещё и вахтенный журнал.

Вторая часть — про журнал. Про то, какие факты об изменении схемы имеет смысл хранить прямо в базе, чем за это платишь и где закопаны грабли, на которые я наступил, чтобы вы могли их обойти.

Когда я только пришел на должность помощника DBA, я заметил, что все production базы фиксируют изменения странным образом, а именно каждый день в 00:00 вызывался скрипт, который выгружает схему БД Firebird, в виде файла script.sql, созданный встроенной утилитой isql. Далее делил весь файл на объекты (файлы), по группам (директориям) принадлежности, объясняю: есть кусок скрипта создания таблицы, он помещается в директорию 01_TABLES в виде отдельного файла названного в честь названия объекта который он содержит, и так далее. Чем же это плохо? А суть в том что разработчиков много, правки анонимны, история тяжело воспроизводимая. В такой каше сразу не разберешься.