davydoffСейчас я использую подход, который привел sti - файлы с переходными скриптами. Есть некоторая базовая схема, к которой применяется скрипт. В итоге схема переходит в другой вид.так все и делают
davydoffСейчас в репозитории каждая таблица (create table) хранится в виде отдельного файла.а как решается проблема со связями между таблицами - тригерами и порядком их создания ? davydoffТеперь представьте, я добавляю новый столбец в таблицу с данными. Я не могу это сделать, изменив файл, где эта таблица создается. Иначе данные будут потеряны. В итоге, я создаю скрипт - выполняется alter table. При этом файл с таблицей тоже надо изменять, чтобы поддерживать исходники в актуальном состоянии. В общем, все нетривиально получается. Для меня проблемы разобраться нет, но придет другой человек и не сможет использовать репозиторий, для того чтобы воспроизвести актуальную схему в БД.для некоторых СУБД есть автоматизированные средства производящие сравнение схемы данных и самих данных в двух базах и генерящие скрипт приведения одной базы в другую. но они не всегда работают и не всегда правильно... :)

http://database-comparison.qarchive.org/

я пробовал EMS DB Comparer for PostgreSQL правда по-моему предыдущую версию или предпредыдущую - была просто не работоспособна. теряла информацию о правах доступа при синхронизации/сравнении, для не совсем уж простых связей просто генерировала битый синтаксически alter скрипт...