Управление версиями кода SQL Server - PullRequest
Новая
       36

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

6 голосов
/ 12 января 2010

Я бы хотел, чтобы все DB DDL-код находился под CVS .

Мы используем Subversion для нашего кода .NET, но весь код базы данных по-прежнему не версионный.

Все, что мы знаем, это насколько важна логика БД. Я гуглил, но нашел только несколько (дорогие инструменты). Я считаю, что существует другое (более дешевое) решение (я).

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

SQL Server 2005, VS 2008 TS, TSVN

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

Меня больше всего интересует среда DEV, где все разработчики имеют полный доступ.
Так что бывает, что разработчик переписал USP, ранее измененный другим.
Я хотел бы иметь возможность восстановить потерянную версию / сравнить ревизии USP и т. Д.

UPDATE-2
Для создания сценария развертывания мы используем Red-Gate SQL Compare.
Работает отлично - поэтому сценарии развертывания не подходят.

Ответы [ 9 ]

3 голосов
/ 12 января 2010

Если вы еще не читали его, статья Мартина Фаулера Evolutionary Database Design - отличное место для начала.

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

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

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

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

2 голосов
/ 12 января 2010

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

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

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

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

1 голос
/ 28 сентября 2010

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

1 голос
/ 14 января 2010

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

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

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

1 голос
/ 13 января 2010

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

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

1 голос
/ 13 января 2010
1 голос
/ 12 января 2010

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

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

1 голос
/ 12 января 2010

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

Randy

0 голосов
/ 13 января 2010

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

...