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

Question

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

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

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

Я прочитал несколько вопросов / ответов в StackOverflow по управлению источниками, связанных с SQL Server (некоторые из них относятся почти к началу StackOverflow), но не нашел каких-либо отличных решений. Кроме того, некоторые записи предшествуют 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) Использование управления исходным кодом SQL Red-Gate (и сравнения SQL) в SQL Server Management Studio.

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

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

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

=====

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Мы оценили выпуск 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, вероятно, не являются азартной игрой, если, конечно, вы сможете справиться с существующими недостатками этого инструмента.

Answer 3

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

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

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

• Является ли RedGate SQL Source Control для меня?
• Предоставление объектов базы данных SQL Server в виде файлов в файловой системе

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