idler 07.11.2009 01:19
Coding — Полуавтоматический Deploy структуры БД в MySQL
Накидал небольшую утилитку на PHP. Позволяет в полуавтоматическом режиме производить деплой стуктуры Баз Данных в проекте.Пользу уже приносит! Стоит в кроне на тестовом сервере после svn update.
А как вы производите подобные миграции?
Похожие
Поделиться
snowemo 07.11.2009 02:23 #
+ 0 -
Меня всегда интересовал вопрос миграции баз данных в крупных проектах, наверное потому что я никогда ничем подобным не занимался. Придется взрослеть и разбираться в этой теме.
Kraplax
Я понимаю, человеку несведущему (то есть мне) это вряд ли понадобится, но не могли бы вы пояснить что такое
Просто может быть как-то или где-то это встретится (или по какой-то касательной уже встречалось), а решение уже готово здесь.
деплой стуктуры Баз Данных
Просто может быть как-то или где-то это встретится (или по какой-то касательной уже встречалось), а решение уже готово здесь.
kstep
Деплой — deploy — развёртывание, установка проекта на сервер.
Решение с развёртыванием ДБ уже есть. Хотя бы та же система миграций в руби-на-рельсах или то, как поступает sqlalchemy в питоне, динамически создающий структуру БД на основе описания классов-моделей. Вот в пхп с этим более напряжно — где ни работал — всё какие-то велосипеды изобретаются.
Решение с развёртыванием ДБ уже есть. Хотя бы та же система миграций в руби-на-рельсах или то, как поступает sqlalchemy в питоне, динамически создающий структуру БД на основе описания классов-моделей. Вот в пхп с этим более напряжно — где ни работал — всё какие-то велосипеды изобретаются.
Я пишу на Django (Python)
внутри Django есть средства работы с БД основываясь только на ORM.
пример команд:
./manage.py syncdb
создает всю БД или новые таблицы еще не созданные
./manage.py evolve --hint --execute
осуществляет эвалюцию базы отнасительно изменившегося кода ORM.
---
т.е. инструменты уже есть. (evolve не радной, и по этому есть узкие моменты с которыми он не справляеться, но для dev'a в полне достаточно)
Для продакшен серваков юзаю тотже evolve, но перед этим проверяю корректность миграции с конкретной ревизии на самую новую.
внутри Django есть средства работы с БД основываясь только на ORM.
пример команд:
./manage.py syncdb
создает всю БД или новые таблицы еще не созданные
./manage.py evolve --hint --execute
осуществляет эвалюцию базы отнасительно изменившегося кода ORM.
---
т.е. инструменты уже есть. (evolve не радной, и по этому есть узкие моменты с которыми он не справляеться, но для dev'a в полне достаточно)
Для продакшен серваков юзаю тотже evolve, но перед этим проверяю корректность миграции с конкретной ревизии на самую новую.
exelens
в одном проекте юзаю. (еще пару буду скоро переводить, когда куплю новый сервак) просто на одном серваке держать 2 СУБД когда не много памяти, полоховато.
Я пытался использовать рельсовый мигратор - не вышло, что-то он у меня не заработал..
Есть недопиленное решение в limb-project.com - тоже работает пока нестабильно.
Выходит инструментов не привязанных к конкретным решениям нет?
То что есть в Limb может не зависеть от всего остального. Тот инструмент САМ создает скрипт, накладывающий изменения в БД. Т.е. так называемый mysql-diff. Но как я уже говорил - работает еще не стабильно.
Есть недопиленное решение в limb-project.com - тоже работает пока нестабильно.
Выходит инструментов не привязанных к конкретным решениям нет?
То что есть в Limb может не зависеть от всего остального. Тот инструмент САМ создает скрипт, накладывающий изменения в БД. Т.е. так называемый mysql-diff. Но как я уже говорил - работает еще не стабильно.
И не удивительно. Строго говоря проблема миграции базы данных между разными версиями приложения — задача нетривиальная, так что пока что надёжнее писать скрипты миграции ручками, чем доверятся разным утилитам вроде mysql-diff. В процессе разработки они, конечно, экономят время, но для продакшены, увы, непригодны категорически, ибо слишком велика вероятность ошибок =(
