См. также 2 часть размышлений об идеальном package manager.
Вот эта вот дискуссия у Бескова -- напомнила мне о всех тех ужасах, которые я переживаю при думании о поддержке баз данных.
В жизненном цикле ПО, особенно серверного, базе данных отведено отдельное место
* БД почти всегда обновляется, и почти никогда не ставится с нуля. Исключение -- только установка новых инсталляций продукта
* Я не знаю никаких встроенных в известные RDBMS инсталляторов схемы - с инкрементальными патчами, версиями модулей и т д. А их очень не хватает
В минимальном виде идеальный package manager должен уметь делать следующее
* вести помодульный реестр установленных в БД компонентов
* позволять инсталлировать/деинсталлировать модули.
* вести зависимость между модулями.
* позволять установить БД "с нуля", накатывая патч за патчем до определенной версии
* инсталляционные скрипты должны быть в виде .sql-файлов (желательно)
В идеале, система должна иметь одинаковый интерфейс под всеми RDBMS.
Может быть, пришло время для какого-нибудь DB Maven? :)
PS: несколько ссылок
* http://www.agiledata.org/essays/tools.html
* http://autopatch.sourceforge.net/documentation.php
* http://migratedb.sourceforge.net/
UPD от 13 Cен: http://www.liquibase.org
UPD 19 янв 09:
* http://db.apache.org/ddlutils/index.html
UPD 9 авг 09:
Подборка относительно недавних проектов, привносящих в .Net мир ruby style migrations
UPD 9 авг 09:
Подборка относительно недавних проектов, привносящих в .Net мир ruby style migrations
- http://www.rikware.com/RikMigrations.html
- http://code.google.com/p/migratordotnet
- http://code.google.com/p/octalforty-wizardby
6 комментариев:
Из своего опыта - имея сравнительно небольшое число инсталляций и минимальный размер поодерживающей команды оказывается заметно проще на всех инсталляциях иметь один и тотже комплект всего, только включая и выключая модули в приложении. таким образом теряется необходимость что-либо деинсталлировать ;)
ну, деинсталлировать по факту мне тоже не приходилось ни разу, за исключением случаев "апдейт не встал, срочно !@$#@# откатываемся"
зато бывает нужны т.н. "опережающие" обновления - когда по каким-либо причинам часть обновлений БД к релизу надо сделать раньше, чем этот самый релиз накатить. Классический пример - триггеры мониторинга и аудита. Их надо накатить ASAP, чтобы уже сейчас мониторилось, а UI для просмотра логов можно и позже установить...
а бэкап? или это от лукавого?
бакап всегда нужен...
но часто бывает так (в MSSQL как минимум), что какой-нибудь неправильный триггер или stored proc может начать делать lock escalation.
и в 1000 раз быстрее удалить триггер, чем ресториться
слова lock escalation напомнили - в teradata есть такая тема: если какой-то view из неважно сколько за-joinенных использует LOCK FOR READ (вместо нормального LOCK FOR ACCESS) то этот лок эскалируется на _все_ таблицы транзакции. То есть вообщем нехитрым селектом можно полбазы остановить, если не быть аккуратным (да, селект часа на полтора в терадате обычное дело)
гламурненько :)
Отправить комментарий