Как сохранить Хранимые процедуры и другие сценарии в репозитории SVN/Other?
Попробуйте следующее:
dict = {0:{1:'a'}, 1:{2:'b'}, 2:{3:'c'}}
for (var key in dict){
console.log( key, dict[key] );
}
0 Object { 1="a"}
1 Object { 2="b"}
2 Object { 3="c"}
10 ответов
Кажется, что Вы не желаете использовать Управление версиями правильно мне.
, Очевидно, одно решение состоит в том, чтобы иметь файлы сценария для всех различных компонентов в каталоге или больше где-нибудь и просто использование TortoiseSVN и т.п. для хранения их в SVN
, Это - то, что должно быть сделано. У Вас была бы своя локальная копия, Вы продолжаете работать (Разработка нового, старая Тонкая настройка, и т.д.) и когда единственные компоненты/процедуры/и т.д. закончены, Вы фиксировали бы их индивидуально, пока Вы не должны запускать процесс.
Фиксирующий полусделанный код просто, потому что это было 'X' время, так как это в последний раз фиксировалось, неаккуратен и гарантировал, что вызвал кого-либо еще использующего горе репозитория.
Я рекомендовал бы , Redgate SQL Выдерживает сравнение для этого - он позволяет Вам сравнивать версии базы данных и генерировать сценарии изменения - это также довольно легко scriptable.
Я нахожу, что он лучше всего рассматривает Хранимые процедуры точно так же, как любой другой компилируемый код: Код живет в репозитории, Вы проверяете его, чтобы внести изменения и загрузить его в Вашем средстве разработки, чтобы скомпилировать или развернуть код.
Можно создать пакетный файл и запланировать его:
- удаляют содержание Вашего каталога
- сценариев с помощью чего-то как ExportSQLScript для экспорта всех объектов в сценарий/сценарии
- svn фиксация
, отметьте: Это, хотя у Вас будут объекты при управлении исходным кодом, у Вас не будет данных, или это - прогрессия (который является переименованным полем, или 1 новым полем и 1 удаленным?).
Этот подход хорошо для поддержания истории изменений. Но, конечно, Вы никогда не должны автоматически соглашаться на "производственную сборку" (если Вам не нравятся поврежденные сборки).
, Хотя Вы не попросили его: Этот подход также не произведет ряд сценариев, которые обновят текущий DB. У Вас только будут первоначальные сценарии создания. Запись сценариев обновления прогрессии и создания данных вне основных систем управления исходным кодом.
На основе Вашего расширенного вопроса Вы действительно хотите использовать триггеры DDL. Выезд эта статья , которая детализирует, как создать систему журнала изменений для Вашей базы данных.
Не уверенный в Вашем диапазоне цен, однако Фантом дБ мог быть опцией для Вас.
я не работаю на эту компанию (или владею продуктом), но в моем исследовании той же проблемы, этот продукт выглядел довольно многообещающим.
Я должен был быть немного более описательным. Рассматриваемая база данных для внутренней ERP-системы, и таким образом у нас нет многих версий нашей базы данных, просто Производство/Тестирование/Разработка. Когда мы сделали запрос на изменение, некоторую новую необычную функцию или что-то, мы просто выполняем сценарий или ряд сценариев для обновления рассматриваемых процедур по базе данных Testing, если это - вся польза, то мы делаем то же к Производству.
, Таким образом, я не действительно после полного сценария схемы по сути, просто что-то, что может отслеживать различные редактирования к хранимым процедурам со временем. Например, PROCESS_INVOICE действительно наполняет. Это обновляется некоторым незначительным способом в марте. Некоторое время спустя в говорят май, обнаружено, что в редком случае клиенты становятся двойными выставленный счет (или некоторый другой сумасшедший угловой случай). Я хотел бы иметь возможность видеть то, что происходило со временем с этой процедурой. В настоящее время способ, которым среда разработки является установкой здесь, у меня нет этого, которое я пытаюсь изменить.
Я записал утилиту для дампа всех соответствующих частей моего дб в структуру каталогов, на которой я использую SVN. Я никогда не находил время для попытки включить его в менеджера, но, если Вам интересно, это здесь: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx
Это свободно и, так как я регулярно выполняю его, Вы знаете, что любые ошибки исправлены быстро.
Я могу рекомендовать DBPro, который является частью Выпуска Команды Visual Studio. Использовали его в течение нескольких месяцев для хранения всех частей базы данных в Сервере Основы Команды, а также для развертывания, и база данных выдерживает сравнение, и т.д.
, Конечно, как кто-то еще упомянул, это действительно зависит от Вашей среды и диапазона цен.
Можно всегда пытаться интегрировать SourceSafe с SQL Server. Вот быстрый запуск: ссылка . Для работы с ним, у Вас должен быть Выпуск Разработчиков Studio Managment.