Проблема не в том, чтобы поддерживать сценарий или поддерживать «главную» копию базы данных. Настоящая проблема заключается в обновлении существующих баз данных. Вы вносите изменения в среду разработчика, которые затем распространяются в тестовую среду и, наконец, помещаются в производственную среду. Хотя на этапе разработки и тестирования среды можно начинать с нуля, в производственной среде всегда необходимо обновить существующее развертывание.
По моему опыту, лучше всего использовать сценарии обновления . Эта практика полезна даже для одного развернутого сайта, но она становится неоценимой для нескольких местоположений, которые могут иметь разные версии. Но даже с одним действующим сайтом все еще полезно иметь возможность многократно тестировать обновление (начиная с резервных копий текущей версии), сохранять изменения в системе контроля версий, иметь хорошо формализованную и проверенную процедуру изменений (скрипт обновления). А сценарии обновления могут быть адаптированы к конкретным потребностям рабочего сайта, например, обрабатывать большую таблицу с особой тщательностью, или иметь дело с зашифрованными данными, или что-либо из множества инструментов, основанных на различиях в деталях, игнорировать или игнорировать. Основным недостатком является необходимость написания сценариев, которые требуют реальных знаний T-SQL (забудьте о «дизайнерах» в вашем любимом инструменте управления).