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

Question

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

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

Мои оговорки ...

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Это, конечно же, упрощается.

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

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

Я также рекомендую прочитать Мартина Фаулера "Evolutionary Database Design" какое-то вдохновение

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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