Как вы справляетесь с управлением конфигурацией таблиц базы данных?
Как вы справляетесь с управлением исходным кодом и автоматическим развертыванием (управлением конфигурацией) таблиц базы данных. Я работаю в среде SQL Server, и довольно легко написать сценарий drop и создать файлы для хранимых процедур / триггеров / функций, даже для заданий. Также легко создать сценарий создания новой таблицы db. Однако, если позже вы захотите изменить эту таблицу, вы не можете просто отбросить ее и воссоздать с новым полем из-за страха потери данных. Есть ли автоматизированный способ решения этой проблемы? Вы создаете сценарий временной таблицы и обратной засыпки после обновления новой измененной таблицы? (может быть грубо, если данных много)
Любые предложения будут ценны.
Ответы 6
Это зависит от того, как вы хотите обрабатывать существующие данные и насколько обширны изменения схемы, но даже в Management Studio перед фиксацией изменений вы можете сгенерировать сценарий всех изменений.
Для большого количества данных или при наличии ограничений или внешних ключей даже простые операции ALTER могут занять значительное время.
Доступны инструменты, которые помогут вам разработать схему, разработать изменения, отредактировать эти изменения и сравнить различия между версиями и даже сгенерировать SQL для внесения изменений DDL.
Например, ознакомьтесь с Менеджер по изменениям Embarcadero и другими продуктами, предлагаемыми Embarcardero.
Вы можете автоматически создать начальный сценарий создания, но сценарии ALTER действительно нужно вручную кодировать в индивидуальном порядке, потому что на практике вам нужно делать в них нестандартные вещи.
В любом случае вам понадобится какой-то способ создания сценариев применения и отката для каждого изменения и иметь сценарий установщика, который их запускает (и откат, который, конечно же, откатывает их). Такой установщик, вероятно, должен запомнить, в какой версии находится схема, и выполнить все необходимые миграции в правильном порядке.
Смотрите мою статью здесь:
http://marksverbiage.blogspot.com/2008/07/versioning-your-schema.html
Такие инструменты, как SQL Compare от Red-gate, неоценимы для того, чтобы убедиться, что у вас есть полный сценарий. Возможно, вам все равно придется вручную настроить его, чтобы убедиться, что объекты написаны в правильном порядке. Убедитесь, что сценарии триггеров, ограничений и т. д., А также таблиц. В общем, вы захотите использовать команды alter вместо drop и create, особенно если таблица вообще большая.
Все наши таблицы, функции и хранимые процессы также должны находиться под контролем источника, поэтому при необходимости мы можем вернуться к старым версиям. Также наши dbas периодически удаляют все, что они находят не в Source COntrol, чтобы разработчики не забыли это сделать.
Конечно, все сценарии разработки, которые продвигаются в производство, должны быть сначала запущены на сервере контроля качества или промежуточном сервере, чтобы убедиться, что сценарий будет работать правильно (и без каких-либо изменений), прежде чем он будет запущен на продукте. Также необходимо учитывать время запуска на продукте, вы не хотите блокировать пользователей, особенно в периоды занятости, и время показало, что загрузка скриптов в производство поздно вечером в пятницу, как правило, плохая идея.
Забыл сказать, что перед загрузкой изменений схемы в рабочую среду убедитесь, что у вас есть хороший набор резервных копий базы данных. Береженого Бог бережет.
У нас был аналогичный опыт работы с Oracle DB. Мы установили процедуры для принятия SVN и автоматизированных скриптов (которые извлекают изменения из SVN) для создания исправлений. Пожалуйста, см. http://www.scmsupport.com/scm.php?go=home.html и http://scmsupport.wordpress.com/ для получения более подробной информации.