Является ли RedGate SQL Source Control для меня?

Я только что унаследовал базу данных SQL Server. Одна из вещей, которые мне нужно будет решить, - это управление версиями и автоматические сборки.

Было высказано предположение, что я должен серьезно подумать о рекомендации RedGate SQL Compare, но я должен признать, что я немного обеспокоен этим.

Мои заказы...

  • по-видимому, способствует использованию инструментов gui для работы db?
  • для живых приложений, я предпочитаю работать со сценариями изменений, это позволяет избежать последней минуты паники для создания сценариев миграции в конце каждого цикла схватки, а это означает, что скрипты обновлений могут быть проверены CI. Я не вижу, как инструмент RedGate обращается к этому.

Мой инстинкт кишки подсказывает мне придерживаться проверенного подхода к файлу MSBuild и стека файлов .SQL.

Мне было бы интересно узнать, есть ли у кого-нибудь опыт использования этого инструмента.

ОТВЕТЫ

Ответ 1

Мы используем Red Gate для создания сценариев для развертывания и управления версиями.

"Развертывание" и "управление версиями" являются отдельными проблемами для кода SQL.

Важно отметить: ваша производственная база данных является мастером со всеми ее данными. Поэтому организуйте регулярные копии тестового сервера и используйте это как базовый уровень. База данных, созданная NUnit каждую ночь с базовыми данными (видел, смеялась), как правило, бесполезна. Что делать, если у вас есть миллиард строк и вам нужно протестировать запрос?

Версии: вы можете использовать инструменты Red Gate для создания схемы в качестве базовой линии, а затем сравнить ее с этой копией (или вашим QA или любым другим). Инструменты Red Gate позволяют сравнивать с папкой, находящейся под управлением SVN, в нашем случае и обновляются каждый выпуск. Таким образом, у нас есть полная история каждого объекта

Развертывание: мы применяем наши сценарии разработки (также в SVN) к чистой базе данных "build" и сравниваем с другой чистой БД. Это станет нашим развертыванием script.

Это, конечно, довольно упрощено.

Про версия предлагает API для синхронизации и сравнения, поэтому при необходимости можно интегрировать в свою цепочку инструментов. Нет необходимости в GUI. Кстати, мы используем это, чтобы обеспечить синхронизацию с одним кликом некоторых специальных песочниц пользователя с кодом клиента.

Как упоминал Ремус, они не являются надежными для некоторых операций. Если вы меняете вещи на 1,5 ТБ-таблицах, я бы с любовью сделал handcode мой script. Еще одно раздражение заключается в том, что инструмент Red gate имеет привычку отбрасывать SCHEMABINDING на соответствующем представлении или udf для простого изменения ограничения проверки.

Я также рекомендую прочитать "Мартин Фаулер" "Дизайн эволюционной базы данных" для вдохновения

Ответ 2

Я бы предпочел также сценарии - легко хранить в исходном контроле (CVS, Git и т.д.), чтобы вы могли различать их, когда делались изменения.

Ответ 3

Я не доверяю средствам, основанным на разности, для развертывания. И это включает vsdbcmd.schema файлы, так как они также основаны на diff. В прошлый раз, когда я попытался использовать инструмент diff, он с радостью предложил изменить таблицу 1,5 ТБ с помощью copy/drop/rename...

Мой подход - всегда использовать сценарии обновления, которые перемещают развернутую схему из v. N в v. N+1. Таким образом, я точно знаю, как выполняется обновление, и если операция невозможна (для этого потребуется операция копирования размера данных, продолжающаяся 2 недели...), тогда я знаю, что не могу этого сделать, и я планирую изменения кода для выпуска v. Далее, соответственно.

Ответ 4

SQL Compare может либо генерировать миграцию SQL script, которая может быть независимо рассмотрена перед ее применением, но также дает возможность выполнить script внутри инструмента. Red Gate рекомендует использовать прежний метод при развертывании в производственные базы данных.

Для управления версиями баз данных SQL Source Control поддерживает большинство систем управления версиями (например, SVN, TFS и т.д., хотя поддержка VSS устарела). В v3 есть опция для ссылки на рабочую папку, позволяющую вам использовать свой собственный клиент управления версиями, если это желательно.

Ответ 5

У меня есть проект с открытым исходным кодом (лицензирован под LGPL), который пытается решить проблемы, связанные с правильной версией схемы DB для (и более) SQL Server (2005/2008/Azure), bsn ModuleStore.

В принципе, отдельная часть набора инструментов скриптирует объекты базы данных SQL Server схемы БД в файлы со стандартным форматированием, поэтому содержимое файла изменяется только в том случае, если объект действительно изменился (в отличие от сценариев сделанный VS, который также создает скрипты и т.д., отмечая все измененные объекты, даже если они фактически идентичны).

Но набор инструментов выходит за рамки этого, если вы используете .NET: он позволяет встраивать скрипты SQL в библиотеку или приложение (в виде встроенных ресурсов), а затем сравнивать сравниваемые встроенные скрипты с текущим состоянием в базе данных. Изменения, не связанные с таблицей (те, которые не являются "деструктивными изменениями" по определение Мартина Фаулера), могут применяться автоматически или по запросу (например, создание и удаление объектов, таких как представления, функции, хранимые процедуры, типы, индексы) и сценарии изменения (которые необходимо записать вручную) могут быть применены в том же процессе; также создаются новые таблицы, а также их установочные данные. После обновления схема БД снова сравнивается с сценариями, чтобы обеспечить успешное обновление БД до того, как изменения будут совершены.

Обратите внимание, что весь код сценариев и сравнения работает без SMO, так что у вас нет болезненной зависимости SMO ​​при использовании модуля bsn ModuleStore в приложениях.

В зависимости от того, как вы хотите получить доступ к базе данных, набор инструментов предлагает еще больше - он реализует некоторые возможности ORM и предлагает очень хороший и полезный интерфейсный подход для вызова хранимых процедур, включая прозрачную поддержку XML с собственным .NET XML классов, а также для TVP (Table-Valued Parameters) как IEnumerable<PocoClass>.

Ответ 6

Мы используем инструмент сравнения как часть нашего процесса развертывания, чтобы увидеть, нет ли чего-то, что требуется для script, и затем обсудите его с разработчиком, если это так (обычно это отличие, которое не проверяется на основании потому что его нельзя перемещать, чтобы перейти к prod). Но мы всегда используем скрипты, которые находятся в исходном управлении. Если вы полагаетесь на SQL Compare или любой другой инструмент сравнения, вы можете обнаружить, что перемещаете вещи, которые еще не должны перемещаться.