Как вы перемещаете изменения базы данных разработчика в производственную базу данных?

Question

Я работал над проектом и прошел его через первый этап. Однако требования закончились изменением, и мне нужно добавить новые таблицы и повторить некоторые ссылки на внешние ключи в БД.

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

Какие существуют стратегии для миграции изменений схемы базы данных и поддержания данных в базе данных?

Насколько мне известно об этом, откройте Sql Server Management Studio и начните добавлять таблицы вручную. Я знаю, что это, вероятно, плохой способ сделать это, поэтому ищу, как это сделать правильно, понимая, что, возможно, я начал неправильно.

Answer 1

Для поддержки изменений схемы вы можете использовать ApexSQL Diff , инструмент сравнения и синхронизации схем SQL Server и SQL Azure, а для поддержки данных в базе данных вы можете использовать ApexSQL Data Diff средство сравнения и синхронизации данных SQL Server и SQL Azure.

Надеюсь, это поможет

Отказ от ответственности: я работаю в ApexSQL в качестве инженера службы поддержки

Answer 2

У вас должно быть что-то, что называется "KIT".Очевидно, что если вы поддерживаете какой-то элемент управления исходным кодом, все сценарии изменений, которые вы делаете в средах разработки, должны поддерживаться в средстве настройки управления исходным кодом.

Как только вы закончите со всеми сценариями/ изменения, которые вы считаете сертифицированными для перехода в следующую более высокую среду.Подготовьте комплект, в котором все эти сценарии находятся в папках (в идеале - в виде процедур, таблиц, функций, начальной загрузки), а затем создайте пакетные файлы, которые могут выполнять эти сценарии в наборе в определенном порядке с помощью служебной программы командной строки OSQL.1004 * Имеются отдельные командные файлы для UAT / Staging / production, так что вы можете просто дважды щелкнуть по командному файлу, чтобы запустить комплект на соответствующем сервере.Проверьте параметры OSQL.

Таким образом, все ваши среды синхронизируются!

Answer 3

Red Gate SQL Compare и SQL Data Compare полностью.С тех пор, как моя компания купила ее, она сэкономила мне массу времени на переводе наших баз данных с DEV на TEST на ACCEPTANCE на PRODUCTION.

И вы также можете синхронизировать ее с папкой scripts для легкой интеграции в систему управления версиями.

http://www.red -gate.com

Answer 4

Обычно я использую что-то вроде Мастер публикации SQL Server для создания сценариев изменений SQL. Это довольно простой и легкий подход. Основным недостатком этого инструмента является то, что производимые будут отбрасывать и воссоздавать таблицы, которые не были изменены, но использовались в измененных процедурах (и я не могу понять, почему), поэтому для прохождения сценария требуется некоторый ручной труд. вещи, которые не должны быть там.

Обратите внимание , что вам не нужно загружать и устанавливать этот инструмент; Вы можете запустить его из Visual Studio. Щелкните правой кнопкой мыши соединение в обозревателе серверов и выберите «Опубликовать в поставщике» в контекстном меню.

Answer 5

Вы можете использовать Visual Studio 2015. Перейдите на Инструменты => SQL-сервер => Сравнение новой схемы

шаг 1) Выберите источник и цель База данных. Нажмите Сравнить вариант.

шаг 2) после завершения сравнения вы можете нажать на иконку Создать скрипт (Shift + Alt + G)

это сгенерирует скрипт Commit .

шаг 3) Чтобы сгенерировать откат скрипт для изменения базы данных, просто swap база данных с шаг 1

Answer 6

Возможно, вы захотите проверить такой инструмент, как Liquibase: http://liquibase.org/

Answer 7

Есть несколько инструментов, которые помогут вам в этом.

Если у вас есть выпуск Visual Studio Team, проверьте проекты базы данных (также известный как DataDude или Visual Studio Team для специалистов по базам данных) См. Здесь и здесь

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

Для VS 2008, убедитесь, что вы получаете патчи GDR2.

Answer 8

Хороший инструмент для проектирования баз данных (например, Sybase Powerdesigner) позволит вам создавать конструктивные изменения в модели данных, а затем генерировать код для реализации этих изменений. Затем вы можете сохранить и запустить код по своему усмотрению. Этот инструмент также должен уметь выполнять обратный инжиниринг, когда вы наследуете базу данных, которую вы не создавали.

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

Answer 9

Мы нашли, что лучший способ протолкнуть изменения - это обрабатывать изменения базы данных как код.Все изменения в скриптах, они находятся в системе контроля версий и являются частью версии.Ни при каких обстоятельствах ничто не подталкивает к тому, чтобы это не было написано в сценарии и в управлении исходным кодом.Таким образом, вы случайно не отправляете изменения, которые есть в dev, но еще не готовы к тому, чтобы их подталкивали к продукту.Кроме того, вы можете восстановить данные prod в окне dev и перезапустить все сценарии, которые еще не были загружены, и у вас есть свежие данные и вся работа dev сохранена.Это также прекрасно работает, когда у вас есть значения поиска в таблицах, которые не изменяются, и вы не хотите, чтобы их подталкивали, пока другие вещи также не будут перемещены.Сценарий вставки и вставьте его вместе с остальным кодом для версии.

Приятно использовать эти инструменты для сравнения, чтобы увидеть, не пропущено ли что-то в сценариях, но я НИКОГДА не буду полагаться только на них.,Слишком большой риск подтолкнуть что-то "еще не готовое к прайм-тайму", чтобы подтолкнуть.