Прежде всего, убедитесь, что у вас есть весь сценарий сборки базы данных, чтобы при необходимости можно было перестроить базу данных.
Каждое изменение должно быть записано как сценарий обновления. Таким образом, вы можете запускать каждое изменение индивидуально для ваших баз данных.
После того, как изменение было зафиксировано в базе кода, объедините сценарий изменения с процессом сборки, чтобы это происходило автоматически ... а затем заархивируйте сценарий изменения в случае возникновения каких-либо вопросов.
Прежде всего, внесите все изменения базы данных в сценарии и поместите их в систему управления версиями.
Затем удалите все разрешения на производство, которые есть у разработчиков. Ровно два человека должны иметь права на производство в магазине малого и среднего размера, назначенный dba и его или ее назначенный заместитель. Как только разработчики не смогут вносить изменения в prod, вам будет легче заставить их писать и использовать сценарии.
Никогда не запускайте скрипт на продукте, который не был сначала загружен в отдел контроля качества или постановку. Если есть проблемы со сценарием, их следует найти здесь.
В настоящее время мы используем набор инструментов Redgate, который содержит Database Compare, Data Compare и т.д.
Вы также можете использовать любой контроль исходного кода для отслеживания изменений объектов базы данных.
Не уверен, о чем вы спрашиваете, но если это хороший способ управлять изменениями схемы и синхронизировать их между версиями и развертываниями, то трудно ошибиться с Visual Studio Database Edition. Ее единственная цель в жизни - управлять изменениями схемы базы данных, проверять схему, создавать и генерировать сценарии развертывания. Если у вас есть Visual Studio Developer Edition или Visual Studio Team Suite, вы можете получить его бесплатно.
Используйте идемпотентные скрипты изменения (и, возможно, посмотрите LiquiBase или dbdeploy ).