Как обновить схему базы данных SQL Server?

ведение списка всех сценариев изменений, применяемых к базе данных dev, и их применение к рабочей базе данных при развертывании.

кроме того, используйте сторонний инструмент, который может сравнить две схемы и предоставить changescript, который затем можно запустить.

Я пытаюсь использовать такие инструменты, как Редгейт в SQL сравнить который покажет вам "различия" между двумя версиями и фактически выпишет компоненты, которые отличаются. Вы также можете сделать привычкой сценарий всех изменений базы данных, так что у вас есть аудиторский след внесенных изменений и можно применить их программным способом, когда вы будете готовы к развертыванию.

лучше всего реализовать ваши изменения в виде набора сценариев diff. Поэтому вместо того, чтобы отбрасывать таблицу и воссоздавать ее, вы пишете как ALTER TABLE.

есть также инструменты, которые помогут вам сделать это. Если вы сохраните копию исходной и новой базы данных, вы можете запустить инструмент против двух, которые будут генерировать SQL, который будет принимать вас от одной версии к другой.

Мне лично нравится обновлять полные сценарии создания, а также поддерживать сценарий обновления, когда я меняю схему для определенного выпуска. Я использовал Red Gate SQL Compare, и это очень хороший инструмент, но предпочитаю поддерживать скрипты.

всегда пишите сценарий, чтобы внести изменения в схему. Поместите сценарий в папку продвижения, чтобы при продвижении изменений сценарии выполнялись для изменения каждой среды.

Migrator Dot Net является удивительным инструментом для управления версиями вашей базы данных. Трудно вернуться к ручному отслеживанию сценариев и выполнению сравнений баз данных после использования миграции.

Visual Studio Database Edition довольно хорошо в этом. Он сохраняет всю вашу схему в исходных сценариях под контролем источника вместе с остальной частью вашего кода. Он может анализировать вашу схему для зависимостей при внесении изменений. Он может выполнять анализ передовой практики. И он может генерировать .dbschema файл, который может используется средством развертывания для обновления базы данных до текущей схемы.

вы можете фактически автоматизировать это с интеграцией continuos и построить падает прямо в тестовую среду, промежуточную среду и даже производственную среду. Это означает, что при регистрации в тестовой ветви машина сборки будет создавать продукт, запускать тесты проверки сборки и развертывать его на сервере разработки. При обратной интеграции из ветви тестирования в основную ветвь машина сборки создает продукт, запускает BVTs и развертывает его на промежуточном сервере тестирования/принятия. И когда вы интегрируете в ветвь выпуска, машина сборки будет строить, тестировать и, наконец, развертывать на производстве. Теперь это правда, не многие org готовы зайти так далеко и позволить процессу сборки continuos автоматически развертываться на живых производственных серверах, и я считаю, что это своего рода радикальное мышление. Но я говорю, что вы должны больше доверять своим автоматизированным BVTs и автоматизированным процессам, чем любому ручному тестированию и развертыванию.

Попробуйте DBSourceTools.
http://dbsourcetools.codeplex.com
Его с открытым исходным кодом, и будет скрипт всей базы данных
- таблицы, представления, процессы и данные на диск, а затем позволяют повторно создать эту базу данных через цель развертывания.
Он специально разработан, чтобы помочь разработчикам получить свои базы данных под контролем исходного кода.