Как сохранить хранимые процедуры и другие скрипты в SVN / другом репозитории?

Question

Может ли кто-нибудь привести некоторые реальные примеры того, как лучше всего хранить файлы сценариев для представлений, хранимых процедур и функций в SVN (или другом) хранилище.

Очевидно, что одно из решений состоит в том, чтобы иметь файлы сценариев для всех различных компонентов в каталоге или где-то еще и просто использовать TortoiseSVN или тому подобное для сохранения их в SVN. Затем, когда необходимо внести изменения, я загружаю сценарий в Management Studio и т. Д. Я не очень хочу этого.

Что бы я действительно предпочел, это какой-то пакетный скрипт, который я мог бы запускать периодически (по ночам?), Который экспортировал бы все хранимые процедуры / представления и т. Д., Которые изменились за определенный период времени, а затем передал их в SVN.

Идеи

Answer 1

Похоже, вы не хотите правильно использовать Revision Control.

Очевидно, что одним из решений является файлы сценариев для всех разных компоненты в каталоге или более где-то и просто используя TortoiseSVN или тому подобное, чтобы хранить их в SVN

Это то, что должно быть сделано. У вас будет локальная копия, над которой вы работаете (разработка нового, настройка старого и т. Д.), И, когда отдельные компоненты / процедуры / и т. Д. Будут завершены, вы будете фиксировать их по отдельности, пока не начнете процесс заново.

Фиксация наполовину выполненного кода только потому, что прошло время 'X' с момента его последней фиксации, является небрежной и гарантированно приведет к тому, что кто-то еще использует горе хранилища.

Answer 2

Вы можете создать пакетный файл и запланировать его:

• удалить содержимое вашего каталога скриптов
• используя что-то вроде ExportSQLScript для экспорта всех объектов в скрипт / скрипты
• SVN коммит

Обратите внимание: несмотря на то, что у вас будут объекты под контролем исходного кода, у вас не будет данных или их последовательности (это переименованное поле или 1 новое поле и 1 удаленное?).

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

Хотя вы и не просили об этом: при таком подходе также не будет создан набор сценариев, которые будут обновлять текущую БД. У вас будут только сценарии начального создания. Запись сценариев обработки данных и создания обновлений выходит за рамки базовых систем контроля версий.

Answer 3

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

Answer 4

Исходя из вашего расширенного вопроса, вы действительно хотите использовать триггеры DDL. Прочтите эту статью , в которой подробно описано, как создать систему изменений для вашей базы данных.

Answer 5

Я бы порекомендовал Redgate SQL Compare для этого - он позволяет сравнивать версии баз данных и генерировать сценарии изменений - он также довольно легко сценариев.

Answer 6

Я написал утилиту для сброса всех соответствующих частей моей базы данных в структуру каталогов, в которой я использую SVN. Я никогда не пытался включить его в менеджер, но, если вам интересно, он здесь: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

Это бесплатно, и, поскольку я регулярно запускаю его, вы знаете, что любые ошибки быстро исправляются.

Answer 7

Я могу рекомендовать DBPro, который является частью Visual Studio Team Edition. Уже несколько месяцев используют его для хранения всех частей базы данных в Team Foundation Server, а также для развертывания и сравнения баз данных и т. Д.

Конечно, как уже упоминал кто-то, это зависит от вашей среды и ценового диапазона.

Answer 8

Вы всегда можете попробовать интегрировать SourceSafe с SQL Server. Вот быстрый старт: ссылка . Для работы с ним вам понадобится Managment Studio Developers Edition.

Answer 9

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

Так что я на самом деле не собираюсь после полного сценария схемы, просто что-то, что может отслеживать различные изменения хранимых процедур с течением времени. Например, PROCESS_INVOICE делает вещи. Он обновляется незначительным образом в марте. Некоторое время спустя, скажем, в мае, обнаруживается, что в редких случаях клиенты получают двойной счет (или какой-то другой безумный угловой случай). Я хотел бы видеть, что со временем произошло с этой процедурой. В настоящее время у меня нет способа настройки среды разработки, которого я пытаюсь изменить.

Answer 10

Не уверен в вашем ценовом диапазоне, однако DB Ghost может быть вариантом для вас.

Я не работаю в этой компании (или не владею продуктом), но в моем исследовании той же проблемы этот продукт выглядел довольно многообещающим.