Инструменты контроля версий для сценариев Visual Studio 2010 и SQL Server 2008 и обновлений баз данных?

В настоящее время мы используем Visual Studio 2010 и SQL Server 2008 R2 - разрабатываем приложения ASP.NET для внутренней сети, которые используют (несколько) баз данных SQL Server.

Мы храним сценарии (для баз данных) для SQL Server в системе контроля версий отдельно от любых инструментов, таких как SQL Server Management Studio (SSMS) или Visual Studio. То есть у нас есть коллекция текстовых файлов, содержащих скрипты для таблиц, хранимых процедур и т. Д.; и мы проверяем их вход и выход из системы контроля версий непосредственно перед их обновлением (например, в Management Studio) и возвращаем их обратно (а затем используем сценарии в SSMS для обновления базы данных).

Теперь мы хотели бы перейти к более комплексному подходу.

Я прочитал несколько вопросов / ответов в Stackru по управлению исходным кодом, связанных с SQL Server (некоторые из них относятся почти к началу Stackru), но не нашел каких-либо отличных решений. Кроме того, некоторые записи предшествуют Visual Studio 2010 или SQL Server 2008 или некоторым доступным инструментам.

Я также читал другие статьи на эту тему, такие как статьи Троя Ханта (один пример: http://www.troyhunt.com/2011/02/automated-database-releases-with.html) и статьи К. Скотта Аллена (например: http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx).

В SQL Server Management Studio есть понятие "проект базы данных", но это явно устаревшая функция, которая не рекомендуется для новых разработок.

Подходы, которые мы рассматриваем на данный момент:

(1) Создайте проект базы данных SQL Server 2008 в Visual Studio 2010 и подключите его к системе управления версиями (например, TFS или VSS). [Для этого варианта может потребоваться Premium, Ultimate или Team Database Edition Visual Studio.]

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

При таком подходе желаемыми функциями являются: глобальный поиск, поиск / замена, рефакторинг, предупреждения об отсутствующих индексах или недействительных элементах и ​​т. Д.

Недостатки: нет дизайнера графического интерфейса для таблиц и других элементов, они могут легко потерять данные с некоторыми изменениями в столбцах (поскольку скрипт "alter" удаляет столбец и создает его заново), отсутствует команда "format document" (доступна в Visual Studio) для веб-проектов, но не для проектов баз данных).

(2) Использование управления исходным кодом Red-gate SQL (и сравнение SQL) в SQL Server Management Studio.

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

Основным преимуществом этого подхода является то, что у вас есть все инструменты и дизайнеры SSMS.

Недостатки заключаются в том, что меньше проверяется целостность проекта, не выполняется поиск / замена или глобальный поиск (без установки других надстроек), а сценарии, созданные с использованием SQL Source Control, синтаксически отличаются от сценариев, сгенерированных собственно SSMS или Visual Studio (конечный результат тот же).

=====

Есть ли у вас предложения для альтернативных подходов, есть ли конкретные инструменты или утилиты, которые вы используете / предпочитаете для интеграции управления исходным кодом для баз данных SQL Server в SQL Server Management Studio или Visual Studio 2010, и как насчет подходов для обновления / синхронизации как разработки, так и производственные базы данных с изменениями?

Я также рассмотрел несколько других программных утилит / инструментов для этой цели (некоторые из них упоминались в других темах Stackru):

SQL Examiner (возможно, хотя это совершенно отдельный инструмент, не интегрированный в SSMS или Visual Studio)

LiquiBase (Apache / Java, пока нет.NET)

NeXtep (пока не поддерживается SQL Server)

DBSourceTools (пока недостаточно интегрирован)

Источник

3 ответа

Решение

Моя организация использовала оба для двух разных проектов, и я стал очень неравнодушным к инструментам RedGate. Как вы упомянули, чтобы получить полную функциональность, вам нужен весь набор инструментов от RedGate, но вы также получите множество дополнительных возможностей (включая рефакторинг или глобальный поиск / замену). Для синхронизации DEV с средами TEST/QA/PROD я использую их продукты сравнения для создания наборов сценариев (которые обычно требуют дальнейшего анализа). Я действительно не доверяю никакому инструменту для обновления используемой схемы, если я не готов быстро восстановить ее.

Напротив, я обнаружил, что инструменты MS слишком сложны, что делало их несколько негибкими. Мы оказались в затруднительном положении, когда у нас были некоторые изменения в БД, которые нужно было синхронизировать с проектом, но изменения в проекте, которые не позволили бы его построить без изменений из БД... это закончилось в целый сценарий "лови 22", который требовал МНОГО ручного редактирования (и привел к тестированию и покупке инструментов RedGate).

Источник

Еще один фактор или критерии, которые вы, возможно, захотите рассмотреть, это то, где вам и вашей команде наиболее удобно писать свои сценарии \ хранимые процедуры и т. Д.

В прошлом мы оценивали выпуск Visual Studio Team Database Edition (или как его сейчас называют) и пришли к печальному выводу, что нам просто было неудобно и мы рады писать SQL из Visual Studio. Мы гораздо более продуктивны как команда, пишущая SQL с использованием SSMS. Вы, конечно, можете найти обратное, чтобы быть правдой.

Мы также занимаемся оценкой инструмента управления исходным кодом SQL в Red-Gate. Самым большим плюсом для нас является то, что он работает в SSMS и является относительно простым. По какой-то причине их модель немного лучше соответствует нашей работе по разработке SQL.

Что касается развертывания, оба продукта, похоже, немного больше склоняются к разработке, где вы внедряете изменения в базу данных, которая находится на ваших серверах. С точки зрения ISV это усложняет создание сценариев развертывания, которые будут выполняться в базе данных вне вашей среды (например, в базе данных, размещенной на сервере клиента).

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

К сожалению, если у вас нет "DBPro" (опять подумайте о клиентском сайте), вам остается использовать VSDBCMD для генерации сценариев изменений из файла схемы. Хотя это работает, было бы неплохо, если бы Microsoft выставила API для VSDBCMD, чтобы можно было создать графический интерфейс, чтобы упростить выполнение для не-разработчиков типов, а не использовать инструмент командной строки.

Трудно представить, что VS Team Database Edition не получит дополнительных возможностей в будущем, поэтому ставки на MS, вероятно, не являются азартной игрой, если, конечно, вы сможете справиться с существующими недостатками этого инструмента.

Источник

Вы не интегрируете контроль исходного кода в базу данных как таковую.

Это не на основе файлов. Ваша база данных состоит из таблиц, кода, данных, индексов, статистики, безопасности и т. Д. Все они находятся в системных таблицах.

Скорее копия + вставка, смотрите мои предыдущие ответы...

Мы следуем "эволюционному проектированию баз данных" Мартина Фаулера более или менее

Источник
Другие вопросы по тегам