Управление версиями кода DDL SQL Server

Если вы еще не читали, статья Мартина Фаулера эволюционный дизайн базы данных - отличное место для Начало.

Статью сложно резюмировать, но в ней описывается, как его команда справлялась с управлением версиями базы данных в быстро меняющемся процессе разработки. Они создали свои собственные инструменты для упрощения работы: сценарии для перехода пользователей к текущему основному устройству, для копирования любой версии схемы, чтобы пользователи могли отлаживать рабочие копии друг друга и т. Д.

В качестве надежного низкотехнологичного решения я счел полезным сохранить в системе управления версиями два типа сценариев DDL:

• Основная версия, которая может создавать объекты базы данных с нуля.
• Скрипты «обновления версии» для каждой итерации разработки.

Они в некоторой степени избыточны, но чрезвычайно полезны (особенно когда дело доходит до развертывания).

Если вы еще не смотрели Visual Studio Database Edition GDR (также известную как «Data Dude»), вам обязательно нужно загрузить и попробовать:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

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

Это бесплатно, если вы используете версию для разработчиков командной системы. Проверить это.

Если вы используете Visual Studio Team Suite или Visual Studio Developer Edition, вы имеете право на копию Visual Studio Database Professional. Это сделано для того, чтобы делать именно то, что вы описываете, и многое другое. Мы используем его для управления схемой (кодом) нашей базы данных.

Рэнди

Мы также используем Subversion для всего кода нашей базы данных. Поскольку ничто не может перейти в Prod, если это не находится в сценарии, похоже, нет проблем с тем, чтобы заставить людей поместить все сценарии в Subversion. Мы обычно пишем сценарии изменения таблиц для изменения таблиц с существующими данными, а затем воссоздаем всю структуру таблицы в случае, если нам нужно создать новую базу данных с нуля (у нас часто есть одна и та же структура базы данных на нескольких серверах, поскольку некоторые из наших клиентов очень большие. и не хотят, чтобы их данные были случайно доступны для конкурентов и поэтому платят за отдельные серверы, и поэтому может потребоваться снова создать всю базу данных без данных.) Для объектов, которые не хранят данные напрямую, мы отбрасываем исходный объект и воссоздаем его с помощью оператор создания. У каждого проекта есть собственный дом в репозитории, как и у каждой базы данных, поэтому сценарий может находиться более чем в одном месте для облегчения развертывания.

Но главное в том, что никто не может загрузиться в Prod без скрипта. Мы не даем нашим разработчикам прямых прав на prod, поэтому у них нет проблем с работой в скриптах, а не с использованием SSMS.

Я написал SMOscript, который генерирует сценарий CREATE для каждого объекта в базе данных.

Используйте этот инструмент для создания каталога, охватываемого CVS, и обновления вашего репозитория.

Наконец, я нашел этот инструмент и подход чрезвычайно полезными и очень легкими для внедрения
(по крайней мере, в начале, когда на месте не было решения для управления версиями):

http://www.codeproject.com/KB/database/SQLScripter.aspx

Запускать можно из коробки.
Для окончательного решения склоняюсь к ГДР.

Это тоже звучит интересно:

Бесплатное ПО:
http://dbsourcetools.codeplex.com/ < br> http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133 < / а>

Коммерческий:
http://www.nobhillsoft.com/Randolph.aspx

Вы должны использовать Management Studio (SSMS) и поместить .sql в систему управления версиями, возможно, отдельные объекты схемы в папках. Надеюсь это поможет

Посмотрите, соответствует ли Wizardby вашим потребностям.