среда, 29 августа 2007 г.

Еще о базах данных - идеальный package manager

См. также 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

6 комментариев:

Viktor Varlamov комментирует...

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

Yury Skaletskiy комментирует...

ну, деинсталлировать по факту мне тоже не приходилось ни разу, за исключением случаев "апдейт не встал, срочно !@$#@# откатываемся"

зато бывает нужны т.н. "опережающие" обновления - когда по каким-либо причинам часть обновлений БД к релизу надо сделать раньше, чем этот самый релиз накатить. Классический пример - триггеры мониторинга и аудита. Их надо накатить ASAP, чтобы уже сейчас мониторилось, а UI для просмотра логов можно и позже установить...

Viktor Varlamov комментирует...

а бэкап? или это от лукавого?

Yury Skaletskiy комментирует...

бакап всегда нужен...

но часто бывает так (в MSSQL как минимум), что какой-нибудь неправильный триггер или stored proc может начать делать lock escalation.
и в 1000 раз быстрее удалить триггер, чем ресториться

Viktor Varlamov комментирует...

слова lock escalation напомнили - в teradata есть такая тема: если какой-то view из неважно сколько за-joinенных использует LOCK FOR READ (вместо нормального LOCK FOR ACCESS) то этот лок эскалируется на _все_ таблицы транзакции. То есть вообщем нехитрым селектом можно полбазы остановить, если не быть аккуратным (да, селект часа на полтора в терадате обычное дело)

Yury Skaletskiy комментирует...

гламурненько :)