Все наши скрипты базы данных проходят несколько этапов тестирования для баз данных, которые похожи на нашу живую базу данных. Таким образом, мы можем быть совершенно уверены, что сценарии модификации будут работать так, как ожидается.
Для отката, хранимых процедур, представлений, функций, триггеров, все программное легко откатить, просто примените предыдущую версию объекта.
Как вы упомянули, сложная часть возникает при обновлении / удалении записей из таблиц или даже при добавлении новых столбцов в таблицы. И вы правы в том, что в этом случае откат может быть столь же вероятным и неудачным.
Что мы делаем, если у нас есть изменение, которое не может быть легко отменено, но является чувствительным / критическим разделом ... это то, что у нас есть набор сценариев отката, которые также проходят через те же среды тестирования. Мы запускаем скрипт обновления, проверяем, что он работает должным образом, а затем запускаем скрипт отката и проверяем, что он работает так же, как и до модификации.
Еще одна вещь, которую мы делаем в качестве меры предосторожности, - это создание моментального снимка базы данных (SQL Server 2005) перед обновлением. Таким образом, если возникнут непредвиденные проблемы, мы можем использовать моментальный снимок для восстановления любых данных, которые могли быть утеряны во время обновления.
Таким образом, самый безопасный способ действий - это тестирование с базами данных, которые находятся максимально близко к вашей действующей системе, а также тестирование ваших сценариев отката ... и на тот случай, если оба из них не пройдут, подготовьте снимок, просто на тот случай, если вам это нужно.