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

StackOverflow https://stackoverflow.com/questions/51288

Вопрос

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

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

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

Идеи?

Это было полезно?

Решение

Мне кажется, вы не хотите правильно использовать систему контроля версий.

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

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

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

Другие советы

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

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

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

Пожалуйста, обрати внимание:Что, хотя у вас будут объекты под контролем источника, у вас не будет данных или их развития (это переименованное поле или 1 новое поле и 1 удалено?).

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

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

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

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

Однако не уверен в вашем ценовом диапазоне. БД-призрак может быть вариантом для вас.

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top