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

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

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

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

Идеи?

Ответ 1

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

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

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

Выполнение кода с половиной кода только потому, что это было время "Х", поскольку оно было последним, было неаккуратным и гарантировало, что кто-то еще использует репозиторий.

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Вы всегда можете попробовать интегрировать SourceSafe с SQL Server. Здесь быстрый старт: ссылка. Чтобы работать с ним, у вас должна быть разработка редакторов Managment Studio.