Как вы справляетесь с управлением конфигурацией таблиц базы данных?

Question

Как вы справляетесь с управлением исходным кодом и автоматическим развертыванием (управлением конфигурацией) таблиц базы данных. Я работаю в среде SQL Server, и довольно легко создавать сценарии удаления и создавать файлы для хранимых процедур / триггеров / функций и даже заданий. Также легко обрабатывать сценарии создания новой таблицы БД. Однако, если позже вы захотите изменить эту таблицу, вы не сможете просто удалить ее и заново создать ее с новым полем, опасаясь потери данных. Есть ли автоматический способ решения этой проблемы? Вы делаете сценарий для временной таблицы и засыпки после обновления новой измененной таблицы? (может быть грубым, если данных много)

Любые предложения будут с благодарностью.

Answer 1

У нас был похожий опыт работы с БД Oracle. Мы создали процедуры для принятия SVN и автоматических сценариев (которые извлекают изменения из SVN) для создания исправлений. Пожалуйста, смотрите http://www.scmsupport.com/scm.php?go=home.html и http://scmsupport.wordpress.com/ для более подробной информации.

Answer 2

Такие инструменты, как SQL Compare от Red-gate, неоценимы для того, чтобы у вас был полный сценарий. Вам все еще может потребоваться настроить его вручную, чтобы убедиться, что объекты написаны в правильном порядке. Обязательно запишите сценарии триггеров, ограничений и т. Д., А также таблиц. В общем, вам нужно использовать команды alter вместо удаления и создания, особенно если таблица вообще большая.

Все наши таблицы, функции и хранимые процедуры также должны находиться под контролем исходного кода, поэтому мы можем вернуться к старым версиям, если это будет необходимо. Кроме того, наши dbas периодически удаляют все, что не находят в Source COntrol, так что разработчики не забывают это делать.

Конечно, все сценарии разработки, продвигаемые в производство, должны быть сначала запущены на QA или промежуточном сервере, чтобы убедиться, что сценарий будет работать правильно (и без изменений), прежде чем он будет запущен на prod. Также необходимо учитывать время запуска на prod, вы не хотите блокировать пользователей, особенно в периоды занятости, и время показало, что загрузка сценариев в производство поздно вечером в пятницу обычно плохая идея.

Answer 3

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

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

Смотрите мою статью здесь:

http://marksverbiage.blogspot.com/2008/07/versioning-your-schema.html

Answer 4

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

Например, посмотрите Embarcadero Change Manager и другие продукты, предлагаемые Embarcardero.

Answer 5

Ох, забыл сказать, что перед загрузкой изменений схемы в производство убедитесь, что у вас есть хороший набор резервных копий базы данных. Лучше быть в безопасности, чем потом сожалеть.

Answer 6

Это зависит от того, как вы хотите обрабатывать существующие данные и насколько обширны изменения схемы, но даже в Management Studio перед фиксацией изменений вы можете сгенерировать скрипт всех изменений.

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