Инструменты управления источником для сценариев 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 для обновления базы данных).

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

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

Я также читал другие статьи по этой теме, такие как статьи Troy Hunt (один пример: http://www.troyhunt.com/2011/02/automated-database-releases-with.html) и К. Скотт Allen (например: 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.]

Этот подход рассматривает script как "мастер", и база данных создается/обновляется с этой целью для синхронизации с версией script.

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

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

(2) Использование Red SQL Server Control (и SQL Compare) в 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 (недостаточно интегрированный)

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Мы следуем за Мартином Фаулером "Evolutionary Database Design" более или менее