Как правильно управлять развертыванием базы данных с помощью проектов баз данных SSDT и Visual Studio 2012?

Я работал над этим сам, и я могу сказать вам, что это не так просто.

во - первых, чтобы обратиться к ответу JT-вы не можете отклонить "версии", даже с декларативной механикой обновления, которую имеет SSDT. SSDT выполняет "довольно приличную" работу (при условии, что вы знаете все переключатели и gotchas) перемещения любой исходной схемы в любую целевую схему, и это правда, что это не требует проверки как таковой, но он понятия не имеет, как управлять "движением данных" (по крайней мере, я не вижу!). Так что, просто как dbproj-файл, вас оставляют вашим собственным устройствам в пре-и пост-скрипты. Поскольку сценарии движения данных зависят от известного начального и конечного состояния схемы, нельзя избежать управления версиями БД. Поэтому сценарии движения данных должны применяться к версионному снимку схемы, что означает, что вы не можете произвольно обновлять БД с v1 до v8 и ожидать, что сценарии движения данных v2 до v8 будут работать (предположительно, вам не понадобится сценарий движения данных v1).

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

первый трюк заключается в отслеживании версий в базе данных (и проекте SSDT). Я начал использовать трюк в DBProj и перенес его в SSDT, и после проведения некоторых исследований оказалось, что другие тоже используют это. Вы можете применить расширенное свойство DB к самой базе данных (назовите его "BuildVersion" или "AppVersion" или что-то в этом роде) и применить значение версии к нему. Затем вы можете захватить это расширенное свойство в самом проекте SSDT, и SSDT добавит его в качестве сценария (затем вы можете проверить параметр публикации, который включает расширенные свойства). Затем я использую переменные SQLCMD для идентификации исходной и целевой версий, применяемых в текущем проходе. После определения разности версий между источником (моментальный снимок проекта) и целью (целевая БД, которая будет обновляться) можно найти все моментальные снимки, которые необходимо применить. К сожалению, это это сложно сделать из внутри развертывание SSDT, и вам, вероятно, придется переместить его в конвейер сборки или развертывания (мы используем автоматические развертывания TFS и имеем для этого пользовательские действия).

следующим препятствием является сохранение снимков схемы с соответствующими сценариями движения данных. В этом случае это помогает сделать скрипты как можно более идемпотентными (то есть вы можете перезапустить скрипты без каких-либо побочных эффектов). Это помогает разделить скрипты, которые могут безопасно быть перезапущен из сценариев, которые должны быть выполнены только один раз. Мы делаем то же самое со статическими справочными данными (словарь или таблицы поиска) - другими словами, у нас есть библиотека сценариев слияния (по одному на таблицу), которые поддерживают синхронизацию ссылочных данных, и эти сценарии включены в сценарии после развертывания (с помощью команды SQLCMD :r). Важно отметить, что вы должны выполните их в правильном порядке, если любая из этих справочных таблиц имеет ссылки FK друг другу. Мы включаем их в основной сценарий после развертывания по порядку, и это помогает нам создать инструмент, который генерирует эти сценарии для нас - он также разрешает порядок зависимостей. Мы запускаем этот инструмент генерации в конце "версии", чтобы захватить текущее состояние статических справочных данных. Все ваши другие сценарии движения данных в основном будут специальными и, скорее всего, будут только одноразовыми. В этом случае, вы можете сделать одну из двух вещей: вы можете использовать оператор if, против дБ сборка / версия приложения, или вы можете уничтожить сценарии 1 раз после создания каждого пакета моментальных снимков.

Это помогает помнить, что SSDT отключит ограничения проверки FK и только повторно включит их после запуска сценариев после развертывания. Это дает вам возможность заполнить новые ненулевые поля, например (кстати, вы должны включить опцию для создания временных "умных" значений по умолчанию для ненулевых столбцов, чтобы сделать эту работу). Однако ограничения проверки FK отключены только для таблиц, которые SSDT воссоздается из-за изменения схемы. В других случаях вы несете ответственность за то, чтобы сценарии движения данных выполнялись в правильном порядке, чтобы избежать жалоб на ограничения проверки (или вы вручную отключили/повторно включили их в своих сценариях).

DACPAC может помочь вам, потому что DACPAC по существу является моментальным снимком. Он будет содержать несколько XML-файлов, описывающих схему (аналогично выходу сборки проекта), но замороженных во времени на момент ее создания. Затем вы можете использовать SQLPACKAGE.EXE или поставщик развертывания для публикации этого снимка пакета. Я не совсем понял, как использовать dacpac versioning, потому что он больше привязан к "зарегистрированным" приложениям данных, поэтому мы застряли с нашей собственной схемой управления версиями, но мы помещаем нашу собственную информацию о версии в имя файла DACPAC.

Я хотел бы иметь более убедительный и выдыхающий пример, чтобы обеспечить, но мы все еще работаем над проблемами здесь тоже.

одна вещь, которая действительно отстой о SSDT является то, что в отличие от DBProj, в настоящее время он не расширяется. Хотя он делает гораздо лучшую работу, чем DBProj во многих разных вещах, вы не можете переопределить его поведение по умолчанию, если вы не можете найти какой-либо метод внутри сценариев pre/post для обхода проблемы. Одна из проблем, которую мы пытаемся решить прямо сейчас, заключается в том, что метод по умолчанию для воссоздания таблицы обновлений (CCDR) действительно воняет, когда у вас есть десятки миллионов записей.

-UPDATE: я не видел этот пост в течение некоторого времени, но по-видимому, он был активен в последнее время, поэтому я подумал, что добавлю пару важных заметок: если вы используете VS2012, выпуск SSDT в июне 2013 года теперь имеет встроенный инструмент сравнения данных, а также предоставляет точки расширения-то есть теперь вы можете включать участников сборки и модификаторы плана развертывания для проекта.