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

Возможный дубликат:
Хранимые процедуры/схема БД в исходном управлении

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

Спасибо

Ответы

Ответ 3

Запишите сценарии миграции для всех изменений db и сохраните их в репозитории. Обеспечьте политику внесения всех изменений в db только запустив script; таким образом, есть запись о том, что было сделано, и способ вернуть его. Изучите, существует ли структура миграции для вашей любимой комбинации языка/db.

Ответ 4

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

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

Вы также можете выбрать создание проекта LINQ (Visual С# → Database) и сохранить весь свой код LINQ в своем репозитории.

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

Ответ 5

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

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

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

Ответ 6

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

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

Update

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

Ответ 7

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

Ответ 8

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