Лучший способ контроля версий T-SQL?

Possible Duplicate:
Stored procedures/DB schema in source control

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

Спасибо

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
13
0
21 447
8

Ответы 8

Напишите сценарии миграции для всех изменений БД и храните их в репозитории. Принудительно применять политику внесения всех изменений в базу данных только с помощью сценария; таким образом есть запись того, что было сделано, и способ отменить это. Узнайте, доступна ли платформа миграции для вашей любимой комбинации языка и базы данных.

Я спросил об этом вчера и получил несколько хороших ответов:

Хранимые процедуры / схема БД в системе управления версиями

Я использую Visual Studio 2008 Pro для создания проектов базы данных (Другие типы проектов -> База данных). Мы уже используем SVN в качестве репозитория кода, поэтому проект с кучей файлов .sql, представляющих ваши хранимые процедуры, - это еще одна вещь, которую нужно поместить в репозиторий - вы можете видеть различия / историю и т. д. Это работает так же с VSS или любым другим репозиторий, который вы используете.

Хорошая вещь в проектах баз данных заключается в том, что ваш проект запомнит вашу строку подключения, и все, что вам нужно сделать, это щелкнуть правой кнопкой мыши файл .sql (или выбрать их все сразу!) И выбрать запустить, чтобы обновить его в базе данных. Это упрощает обновление ваших файлов .sql из репозитория и запускает их все для обновления всех ваших хранимых процедур, проверяя, что ваша база данных обновляется за секунды.

Вы также можете выбрать создание проекта LINQ (Visual C# -> База данных) и сохранить весь свой код LINQ в своем репозитории.

Надеюсь, это поможет!

В статьях К. Скотта Аллена сказано все: http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx

Если вы были очень ленивы, вы могли бы использовать SMO (объекты управления SQL Server) или, если вы используете SQL Server до 2005 года, DMO (распределенные объекты управления), чтобы ежедневно создавать сценарии для всех таблиц / представлений / хранимых процедур, а затем сравнивать сценарий со сценарием в системе управления версиями, и если есть какие-либо изменения, проверьте новую версию. У вас не обязательно будет такой красивый сценарий, как если бы вы только что создали все изменения db в сценариях, но, по крайней мере, вы можете воссоздать все таблицы / сохраненные процедуры / просмотры. Например, в моих сценариях создания таблиц часто встречаются комментарии.

Вот статья, которая поможет вам начать создание сценариев: http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated.

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

Я использую версию базы данных Visual Studio, которая может экспортировать схему из SQL Server в проект Visual Studio. Затем он сохраняется в системе управления версиями и может быть развернут там, где это необходимо. Проект VS Database - это всего лишь набор скриптов, и это неуклюжий способ работы.

Более надежным методом было бы использование инфраструктуры миграции базы данных, и если вы работаете с .Net, ознакомьтесь с этим сообщением в блоге, чтобы получить хорошее описание http://flux88.com/NETDatabaseMigrationToolRoundup.aspx.

Обновлять

Как уже упоминалось в комментариях, этой страницы больше нет. Итак, вот последний известный снимок с машины обратного пути http://web.archive.org/web/20080828232742/http://flux88.com/NETDatabaseMigrationToolRoundup.aspx

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

Я написал триггер DDL, который регистрирует все изменения, внесенные в определение объектов SQL (триггеры, таблицы, SP, представление и т. д.). Я мог бы очень хорошо вызвать расширенный SP из триггера и сохранить детали в другой базе данных и использовать ее в качестве репозитория. Но если ваша команда действительно дисциплинирована, любой контроль версий должен помочь. Триггер используется в качестве механизма аудита и идеально подходит для групп, которые географически разбросаны.

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