Нужна хорошая схема / рабочий процесс для управления объектами базы данных с использованием Subversion

Question

Как вы отслеживаете свои хранимые процедуры, представления и функции в SQL Server и управляете ими?

Я бы хотел использовать Subversion, но, похоже, мне просто нужно сохранить и зафиксировать операторы CREATE / ALTER. Это может сработать хорошо для меня, но я подозреваю, что в конечном итоге я буду ворчать.

Кто-нибудь использует управление версиями со своими базами данных? Есть ли лучший способ?

Раньше люди просто комментировали части кода и оставляли его внутри. Или они добавляли небольшие комментарии "добавлено 31.02.2010". Это сводит меня с ума, потому что я знаю, что есть лучший способ.

Мы регистрируем изменения в заголовке объекта, но это довольно ограничено. Моя жизнь стала бы проще, если бы я мог использовать разные версии.

Дополнительная информация
Мы используем SQL Server 2005. У меня установлены Subversion (через VisualSVN Server) и TortoiseSVN, но я открыт для других предложений.

Под объектами базы данных я имею в виду хранимые процедуры, представления и функции.

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

Я нашел связанный вопрос о версиях хранимых процедур

Answer 1

Мы пишем все и помещаем в Subversion. Ничто не может быть загружено в Prod без сценария (разработчики не имеют прав на prod), и люди с правами на prod принимают только сценарии, загруженные из Subversion.

Answer 2

Посмотрите на liquibase, здесь

Он управляет вашими изменениями / скриптами sql и может применять их вместе с svn через хуки или скрипты. Упрощает все виды настройки и помогает устранить случай отсутствия триггера / sproc / и т. Д ...

Answer 3

Мы пересматриваем нашу базу данных, создание схемы, dw, etl, хранимые процедуры, как и любой другой кусок кода, потому что это код!

Я также видел, как люди вводили даты в заголовках и т. Д. Обычно это происходит из-за того, что они полностью пропускают точку контроля версий.

Answer 4

Всякий раз, когда я проходил это упражнение, он сводился к трем основным вещам, которые должны контролироваться источником:

1. Хранимые процедуры / Представления / Триггеры (более или менее все, что может быть справедливо выражено как «код». Они довольно просты, включают условное удаление и создают в верхней части файла.
2. Таблица схем - операторы DROP / CREATE, как указано выше. Вы можете попытаться привыкнуть к операторам ALTER, но это может привести к очень запутанным последствиям.

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

3. Данные в таблицах. Здесь мы рассмотрели несколько подходов - либо серию операторов INSERT, хранящихся в файле типа «TableName_Data.sql», либо файл CSV с пользовательскими инструментами сборки, которые анализировались и вставлялись при перестройке БД.

В конечном итоге мы пошли с инструкциями INSERT для простоты.

Answer 5

Я не уверен, что вы все подразумеваете под "объектами базы данных". Это только таблицы, представления, процедуры и т. Д. Или также данные? Я имею в виду ежедневно создаваемые данные?

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