Контроль версий с SQL Server

14

Я начинаю новый проект и использую SVN (с черепахой) в качестве моей системы контроля версий. Мне было интересно, возможно ли также поддерживать базу данных SQL Server, используя ту же систему.

Я бы хотел версии моих таблиц / функций / представлений / procs / triggers / и т. Д. но не мои данные, так как все равно это будут тестовые данные. Я не совсем уверен, как это настроить. Я сталкивался с несколькими вариантами, но я хотел бы знать, было ли что-то, что я пропустил, и есть ли руководство или что-то там, чтобы помочь мне начать работать с ним.

Я видел и слышал о Red Gate, но я ищу что-то бесплатное (или, по крайней мере, очень дешевое). Я знаю, что всегда мог написать что-то сам, но на самом деле я не пытаюсь тратить на это время.

Одна вещь, с которой я столкнулся - это пакет с открытым исходным кодом, который называется ScriptDB4Svn . Кто-нибудь использовал это раньше? Это хорошо? Может ли он делать то, что мне нужно, и достаточно ли просто выполнить настройку?

Яннис
источник
1
Has anyone used this before? Is it good? Can it do the things I need it to do and is it pretty simple to get setup?Почему ты боишься попробовать это для себя? Просто возьмите это и поиграйте.
Яннис
@YannisRizos - я определенно буду, если я не получу слишком много ответа от этого, я просто хотел попытаться сэкономить некоторое время и посмотреть, работал ли кто-то с этим раньше, или кто-нибудь пробовал и тестировал сразу это соответствует моим потребностям, чтобы я мог сэкономить время на эксперименты.
Просто заметил, как ты здесь новенький. Программисты SE не являются хорошим местом для того, чтобы задавать вопросы, просто чтобы сэкономить время, мы действительно ожидаем, что вы сделаете что-то подобное для себя, то есть проведите собственное исследование, прежде чем задавать вопросы . Или, альтернативно, спросите в чате (но не ожидайте твердых ответов). Сказав это, это действительно не имеет значения, потому что последнее предложение не является вашим основным вопросом, который на самом деле очень хороший (и правильно помеченный, это редкость для новых пользователей, слава!).
Яннис
@YannisRizos - спасибо. Я прыгаю в чат, чтобы посмотреть, смогу ли я получить какую-то обратную связь для ScriptDB4Svn, и проверю здесь наличие обновлений для основного вопроса. Изменить: Похоже, я не могу общаться, пока у меня есть 20 респ. Ну что ж, терпение, я думаю.

Ответы:

2

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

Кстати, я использовал инструмент RedGate, и он довольно приятный и стоит денег.

JohnFx
источник
Так что, в основном, я выполняю свою работу в Management Studio, а затем экспортирую скрипты в каталог SVN, и в основном делаю это каждый раз, когда я над ним работаю (заменяя старые при каждом экспорте)? Я думаю, это сработало бы. Это позволит сохранить функциональность SVN, чтобы можно было вернуться и заполнить, но да, это было бы своего рода хлопот. Может быть, я проверю расценки RedGate и посмотрю, стоит ли оно того для меня.
@ Скотт - ручной способ может работать, вы просто должны думать о разработке SQL по-другому. Скриптовые версии объектов являются «официальными», а версия в SQL - всего лишь скомпилированная версия. Так же, как ваш исходный код.
JohnFx
Я решил сделать что-то вручную и, возможно, реализовать скрипт, используя помощь по ссылкам, предоставленным Майком Накисом, но сейчас я просто собираюсь использовать встроенный графический интерфейс в Management Studio для экспорта сценариев создания БД после завершения работы. работает, и проверьте их, и пусть SVN сохранит их версию таким образом. Так как я решил сделать что-то вручную, вы получите ответ за то, что мне не нужен инструмент для этого :)
1

Похоже, у вас в основном настройки Microsoft. Вы можете взглянуть на проекты базы данных (ранее известный как DataDude). Они в основном превращают T-SQL в первоклассный язык в Visual Studio; вы можете:

  • Компилировать проекты - он не просто создает окончательный сценарий, он обеспечивает существование имен объектов и т. Д.
  • Выполните статический анализ кода - например, убедитесь, что вы всегда обращаетесь к объектам, включая их схему (например, [dbo]в большинстве случаев) для повышения производительности на 30%.
  • Создавайте diff-скрипты, сравнивая разные версии проекта.
  • Обновите ваш проект из базы данных или скрипта (реверс-инженер).
  • Intellisense.
  • Там нет инструментов для построения диаграмм.

Они также унифицируют ваш код и код вашей базы данных под контролем исходного кода. Если вы работаете над сценариями и создаете сценарии для своих объектов базы данных (вместо использования инструментов Davinci в SSMS), вы также используете одну среду IDE - и это хорошо.

Джонатан Дикинсон
источник
0

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

В моем текущем проекте мы не разрабатываем приложение на Ruby, но мы все еще используем Rails для управления базой данных. Я бы не стал делать это иначе.

Vinnie
источник
Любые руководства, чтобы объяснить это немного больше и перейти к настройке что-то вроде этого?
На самом деле, это не очень хорошая идея использовать Rails вместе с технологиями .NET.
поочередно
Глава по миграции на Rails ( guides.rubyonrails.org/migrations.html ). Этого должно быть достаточно, чтобы начать работу и дать вам всю необходимую информацию о том, почему это хорошая идея. @altern - поскольку вы просто используете Rails для манипулирования и управления версиями базы данных, это должно иметь какое-либо влияние на технологии .NET. Вы сможете получить доступ и использовать БД таким же образом, как если бы вы не использовали рельсы. Я не против увидеть ссылки на ваши проблемы. Разве IronRuby не является реализацией Ruby и Rails .Net?
Винни
> Разве IronRuby не является реализацией Ruby и Rails .Net? IronRuby - это .NET-реализация Ruby . Я не уверен, что Rails работает правильно на IronRuby. Мой общий аргумент против использования Rails для целей управления версиями в db заключается в том, что Ruby и связанные с ним технологии (RoR, migratinos) имеют довольно крутой график обучения, особенно для такой простой задачи, как управление версиями в db. Можно использовать его для других целей, а не только для миграции. В противном случае это только повысит сложность проекта без особого положительного эффекта.
поочередно
0

Это было обсуждено ранее для stackoverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Кроме того, эта внешняя статья предоставляет некоторую дополнительную информацию http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated вместе с примером кода в форме приложения Windows.

Поскольку то, что вы хотите сделать, это то, что я сделал для MS Access самостоятельно, я расскажу вам, что я сделал в случае, если это даст вам некоторые идеи: я написал модуль под названием Ado2Xml, который преобразует схему и данные любого ADO -доступная база данных в xml и обратно. Он знает только о таблицах и представлениях; нет хранимых процедур, нет триггеров, нет ничего. В любом случае, в вашем случае этот модуль заменяется инструментом, который вы, вероятно, найдете, который делает то, что вы хотите с MS-SQL. Таким образом, каждый раз, когда мое приложение запускается, оно сравнивает метку времени базы данных с меткой времени сохраненного XML-файла; Если XML-файл более поздний, он уничтожает базу данных и вызывает Ado2Xml для ее повторного создания из XML-файла. Когда мое приложение заканчивается, он делает обратный: он вызывает Ado2Xml экспортировать базу данных в файл XML. Фактически, объекты ADO, которые извлекают схему базы данных, по какой-то причине ужасно медленны, в результате чего процесс экспорта занимает некоторое время. Поэтому, чтобы избежать необходимости каждый раз ждать завершения моего приложения и Visual Studio переключаться с макета отладки на макет редактирования, прямо перед его завершением мое приложение запускает внешнее приложение для экспорта, чтобы оно могло завершиться немедленно.

Майк Накис
источник
Две ссылки, которые вы предоставили, являются тем, что я, вероятно, заинтересован в настройке самостоятельно, поэтому я могу в основном автоматизировать ручные шаги, которые я делаю прямо сейчас. Спасибо за это!
0

Да, я использовал аналогичный инструмент (разработанный собственными силами) в предыдущем проекте. Он будет записывать все таблицы, представления, sprocs, триггеры и т. Д. В отдельные файлы .sql. Затем у нас был сценарий, который запускался каждую ночь, чтобы «проверить», что все в нашей базе данных «разработки» было отражено в системе контроля версий.

Таким образом, нормальный рабочий процесс является то, что вы хотите изменить свой код, изменить соответствующие таблицы и sprocs в базе развития по мере необходимости, то вы бы запустить инструмент, который мы имели, который бы обновить все скриптовые .sql файлов. Вы бы тогда все проверили.

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

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

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

Дин Хардинг
источник
Можете ли вы уточнить Then, we had a script that ran every night to "validate" that everything in our "development" database was reflected in source control.? Спасибо за ваш ответ.
@ Скотт: я отредактировал ответ, чтобы включить немного больше деталей.
Дин Хардинг