Можно ли использовать проект базы данных MS VS в качестве полного решения для управления базой данных?

StackOverflow https://stackoverflow.com/questions/4137844

Вопрос

В нашем проекте у нас есть несколько производственных баз данных и множество разработчиков. Каждая производственная база данных представляет некоторую «версию субпроекта/локализации». Мы используем SQL Server 2008.

Таким образом, мне нужно разработать стратегию версий базы данных, используя проект базы данных MS Visual Studio. Я прочитал много статей о правилах базы данных и проектах базы данных, но у меня все еще много вопросов:

  1. Как разработчики должны внедрить свои изменения в проект DB? (Лучшая практика)

  2. Как генерировать 100% работоспособную сценарий «Последняя версия» без вмешательства человека (пропуская некоторые объекты, переписывая некоторые изменения и т. Д.)?

  3. Как управлять изменениями данных с помощью проекта базы данных MS Visual Studio? Я знаю о сценариях до/после развертывания, но я думаю, что это не может решить эту проблему. (Пример: мне нужно переназначить какую -то таблицу в другую).

«Идеальное решение» будет:

  1. Разработчики генерирует и поддерживает проект базы данных для базы данных [ProductionDB].

  2. С новым релизом я развернут проект базы данных в [ProductionDB] со всеми необходимыми изменениями.

  3. Разработчики меняют проект базы данных и записывают некоторые сценарии манипуляции с данными для конкретных изменений.

  4. С новым релизом я развернут проект базы данных в [ProductionDB] со всеми необходимыми изменениями.

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

PS: я уже прочитал следующие дискуссии:

  1. Изменения версий базы данных [закрыто
  2. Как вернуть мою базу данных MS SQL в SVN?
  3. Ищу решение для использования версий базы данных
  4. Есть ли система управления версиями для изменений структуры базы данных?
Это было полезно?

Решение

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

  1. Разработчики просто проверяют файлы скрипта базы данных, вносят изменения и проверьте их обратно. Помните, что они будут менять файлы .SQL, а не непосредственно объекты, присутствующие в любой базе данных DEV. Поэтому, если вам нужно добавить два столбца в таблицу базы данных, вы измените сценарий Create Table для этой таблицы и не напишите сценарий альтернативы для этой таблицы.

  2. Если у вас есть целевая старая схема DB - вы можете просто развернуть этот проект с последними файлами в эту базу данных, и будет создан скрипт развертывания (с необходимыми операторами альтернатива). Существует настройка проекта, которая позволяет вам выбрать, должен ли также работать сценарий развертывания против DB при «развертывании».

  3. Сценарий развертывания может быть результатом, который отдельно проверяется на копии Prod, а затем применяется для Prod в качестве патча.

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

Другие советы

То, что вы описали, является причиной того, что проект базы данных существует.

Чтобы ответить на ваши вопросы:

  1. Это зависит от разработчика. Вы можете либо работать в Visual Studio и отредактировать файлы проекта напрямую или редактировать живую копию базы данных в MGMT Studio и использовать схему, сравнивающуюся в VS, чтобы синхронизировать изменения обратно в проект. Я использую его в течение нескольких месяцев и нахожу, что оба работают нормально, хотя я склонен редактировать файлы проекта прямо чаще.

  2. Развертывание проекта генерирует последнюю версию, если вы установите флажок, чтобы сначала сбросить пункт назначения DB. Вы можете сделать это без вмешательства человека, позвонив VSDBCMD во время вашей сборки

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

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

Проблема с данными сложна для решения. Здесь, в Red Gate, у нас было много запросов на это для нашего Управление источником SQL Инструмент, который имеет параллели с проектами баз данных VS. Хорошей новостью является то, что мы активно добавляем поддержку для этого и должны иметь раннюю сборку, чтобы попробовать до Рождества. Если вам интересно, просто подпишитесь на уведомления о раннем доступе на http://www.surveymk.com/s/sqlsourcecontrol_eapsignup Анкет Мы хотели бы получить ваши отзывы.

Вы можете взглянуть на открытый источник BSN Modulestore Toolkit, который пытается реализовать этот рабочий процесс (и он фактически делает больше, чем).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top