Я думаю, у вас есть для каждой версии вашего программного обеспечения куча обновлений базы данных. Почему бы вам не написать эти обновления в виде инструкции T-SQL, которая будет протестирована и выполнена при первом запуске новой версии вашего программного обеспечения? Просто откройте соединение с вашей базой данных из вашего программного обеспечения и отправьте инструкции DDL так же, как вы отправили бы любую инструкцию SELECT или UPDATE. Я также хотел бы сделать нечто похожее на то, что предлагает Джек Полсен: вести список этих инструкций T-SQL с помощью системы двойной идентификации: одна связана с версией базы данных / программного обеспечения, к которой она применяется (может быть uniqueIdentifier), другая (номер) для храните инструкции в последовательном порядке (см. мой пример: инструкция 2 не может быть выполнена до инструкции 1)
Пример:
//instruction 1, batch instructions for version#2.162
USE myDatabase
GO
ALTER TABLE myTable
ADD myColumn uniqueIdentifier Null
GO
//instruction 2, batch instructions for version#2.162
USE myDatabase
ALTER TABLE myTable
ADD CONSTRAINT myTable_myColumn FOREIGN KEY (myColumn) ...
GO
Полное описание инструкций ALTER, DROP и CREATE см. В справке T-SQL. Просто будьте осторожны (например), чтобы удалить Индексы и Ограничения, связанные с полем, перед удалением этого поля.
Конечно, вы можете добавить дополнительные инструкции ОБНОВИТЬ для вычисления значений для добавленных столбцов и т. Д.
Можно даже подумать о чем-то более сложном, проверяя, правильно ли были выполнены предыдущие шаги по обновлению (которые привели к версии базы данных # 2.161).
Мой совет: при написании этих инструкций T-SQL также следите за их «аналогами», чтобы вы могли в любое время (например, время отладки) понизить структуру вашей базы данных до предыдущей версии.