Есть ли инструмент (PHP, Perl, Ruby, shell, SaaS в сети), который может принимать дамп базы данных PostgreSQL, новую схему и переносить (без потери данных)? Работа с удалением и добавлением зависимостей - это немного хлопот.
Короткий ответ: Нет.
Более длинный ответ: волшебное определение пути от схемы A к схеме B выходит за рамки возможностей компьютерной программы, даже такой сложной, как система баз данных. Человеку нужно участвовать.
Процедура обновления вашей базы данных должна включать создание сценария обновления (например, updates-1.3.0.sql), который выполняет соответствующие и необходимые действия, в том числе:
CREATE TABLE, ALTER TABLE и DROP TABLE командыCREATE INDEX и DROP INDEX командыVACUUM (или VACUUM FULL / VACUUM ANALYZE при необходимости)Затем вы сравниваете свою текущую версию схемы (вы можете сохранить ее где-нибудь в БД) со списком сценариев обновления, которые у вас есть, и выполняете сценарии обновления, чтобы перейти к новой схеме.
Например, если вы используете версию схемы 1.2.0 и хотите перейти на 1.3.0, вы должны применить
updates-1.2.1.sql, updates-1.2.2.sql,. . ., updates-1.3.0.sql
Несколько советов по сценариям обновления:
Убедитесь, что все заключено в транзакцию (BEGIN . . . ROLLBACK . . . COMMIT).
Если что-то пойдет не так, вы хотите иметь возможность отменить весь фиаско, не оставляя базу данных в ненадежном / несогласованном состоянии.
Напишите сценарии обновления по мере написания новой схемы.
Фактически, мой обычный метод написания файла SQL для создания новой схемы в пустой БД состоит в том, чтобы разработать сценарий обновления, затем запустить его в пустой базе данных и выгрузить полученную схему - это гарантирует, что сценарий «голого металла» дает результаты, идентичные тому, что вы получили бы в процессе обновления.
Ожидайте, что обновления не будут выполнены - включите подробные ошибки (RAISE EXCEPTION/RAISE NOTICE) и убедитесь, что программы, выполняющие сценарии обновления sql, останавливаются при обнаружении ошибки.