Комментарии 13
Практически в каждом ORM фреймворке есть нормальный инструмент для управления миграциями — поэтому собственная поделка на bash-скриптах имеет смысл только ну разве что для тренировки написания скриптов bash. В работе же лучше пользоваться проверенными временем решениями, которыми пользуется большинство разработчиков. Навскидку под PHP — phinx.org laravel.su/docs/5.0/eloquent
0
Да верно, отчасти это была тренировка в баше )
0
Если речь идет о разработке, к примеру, веб приложения, то да — миграции наше все. Как насчет приложений, которые базируются исключительно на базе данных. К примеру, разнообразные бизнес аналитические тулзы. По факту, там имеется одна, а то и несколько баз данных с кучей таблиц, триггеров и хранимых процедур. Данные туда приходят из разных источников. Отчеты генерятся специальной тулзой. И тут встает вполне резонный вопрос. Как сделать, что бы структура базы с триггерами и процедурами, лежала в гите, и было бы удобно редактировать, смотреть изменения, откатывать изменения админу баз данных.
0
У меня почему-то никогда не возникало необходимости обновлять БД при переключении веток. Если я делаю какую-нибудь фичу с изменением схемы БД, то она чаще всего быстренько вливается в мастер и дальше живётся как обычно. Если всё же приспичит менять схему и не вливать в мастер, то я просто создам отдельную временную базу и не буду париться ни с какими синхронизациями
Контроль структуры таблиц осуществляется через миграции в любой ORM, как уже отметили выше. Бэкапы же данных храниться в git не должны (максимум — небольшой набор фикстур для начальной инициализации свежесозданной БД). Так что всё это выглядит довольно бессмысленно
происходит 500-я и вы не знаете почему
Дык логи читать надо
Для того, чтобы соблюсти контроль версии базы данных используя гит, очевидно нужно получать ее дампы
Не нужно, потому что миграции всё контролируют сами
+1
При хранении дампа БД в Git есть проблема нещадного разрастания размера коммитов, если сама БД довольно большая (например, в случае рабочего сайта с CMS).
А если скрипт упаковать, то он будет хранится обычным бинарным файлом.
А если скрипт упаковать, то он будет хранится обычным бинарным файлом.
0
Миграции? Нет, не слышали :)
0
Согласен со всеми кто против такого подхода. За маленьким исключением. Существует достаточно специфический класс сайтов это типа визитка без контента типа новостная лента и т.п. то есть практически статика. Но при разработке юзается cms с хранением в базе данных. Да там хранить дампы в git вполне допустимо т.к. ещё раз повторю это практически статика.
Автор намекает что имеет дело именно с такими сайтами просто не акцентировал на этом внимание. Хотя этот момент очень важен исходя из такого нестандартного решения
Автор намекает что имеет дело именно с такими сайтами просто не акцентировал на этом внимание. Хотя этот момент очень важен исходя из такого нестандартного решения
0
Для таких сайтов достаточно единственного скрипта без какой либо интеграции с git. Это проще и значительно понятнее.
Например для Drupal 7
#!/bin/bash
# one argument: the file of config.php file
d7config=$1
if [ ! -f "$d7config" ]; then
echo "File '$d7config' not found."
exit
fi
db=`cat $d7config | grep " 'database' => '" | awk -F"'" '{print $4}'`
if [ -z $db ]; then
echo "Database name not found in $d7config."
exit
fi
user=`cat $d7config | grep " 'username' => '" | awk -F"'" '{print $4}'`
if [ -z $user ]; then
echo "Database user not found in $d7config."
exit
fi
pw=`cat $d7config | grep " 'password' => '" | awk -F"'" '{print $4}'`
if [ -z $pw ]; then
echo "Database credentials not found in $d7config."
exit
fi
#pr=`cat $d7config | grep " 'prefix' => '" | awk -F"'" '{print $4}'`
tables_cmd=""
ignore_cmd=""
for t in "%cache%" "%history" "%search_%" "%sessions" "%watchdog" "%accesslog"
do
for t2 in `mysql $db --user=$user --password=$pw -Bse "show tables like \"$t\";"`
do
tables_cmd="$tables_cmd $t2"
ignore_cmd="$ignore_cmd --ignore-table=$db.$t2"
done
done
# Дамп данных без временных данных и кеша, одна строка данных в строке, без даты создания дампа, без создания БД. Добавление и удаление таблиц и все в одну транзакцию
mysqldump --user=$user \
--password=$pw \
--extended-insert=FALSE \
--skip-dump-date \
--no-create-db \
--add-drop-table \
--single-transaction \
$ignore_cmd \
$db \
> mysqldump.sql
# Дамп только структуры таблиц без данных, без даты создания дампа, без создания БД + добавить удаление таблиц
mysqldump --user=$user \
--password=$pw \
--databases $db \
--skip-dump-date \
--no-create-db \
--add-drop-table \
--no-data \
--tables $tables_cmd \
>> mysqldump.sql
0
Ну понятно что возможно автор не использует какой то Фреймворк типа yii2, laravel или Django. Но просто автор уж очень сильно уходит на «тёмную сторону», он и сразу пишет что исправления все на live сервере/сайте. То есть все как то уж очень по суровому. Если уж так все сурово сразу то зачем бекапы то тогда :)
0
Я прекрасно понимаю, что есть миграции, и знаю что делать когда есть 500 итд, но помимо yii2, laravel или Django итд существует 100500 CMS и самописных монстров, которые развиваются небольшими командами и постепенно перемещаются в пекло из-за гуанокодеров и развития технологий. Правильная настройка конфига позволяет сохранять только структуру без содержимого, тогда рост минимален в таком случае, а что уж с ней делать потом это второй вопрос. Я думаю что если разраб будет пользоваться снимками структуры, то он прекрасно знает как этот вопрос решить.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Механизм контроля версий базы данных в GIT (управление дампами MySQL)