Обновить
Комментарии 13
Практически в каждом ORM фреймворке есть нормальный инструмент для управления миграциями — поэтому собственная поделка на bash-скриптах имеет смысл только ну разве что для тренировки написания скриптов bash. В работе же лучше пользоваться проверенными временем решениями, которыми пользуется большинство разработчиков. Навскидку под PHP — phinx.org laravel.su/docs/5.0/eloquent
Да верно, отчасти это была тренировка в баше )
Если речь идет о разработке, к примеру, веб приложения, то да — миграции наше все. Как насчет приложений, которые базируются исключительно на базе данных. К примеру, разнообразные бизнес аналитические тулзы. По факту, там имеется одна, а то и несколько баз данных с кучей таблиц, триггеров и хранимых процедур. Данные туда приходят из разных источников. Отчеты генерятся специальной тулзой. И тут встает вполне резонный вопрос. Как сделать, что бы структура базы с триггерами и процедурами, лежала в гите, и было бы удобно редактировать, смотреть изменения, откатывать изменения админу баз данных.

У меня почему-то никогда не возникало необходимости обновлять БД при переключении веток. Если я делаю какую-нибудь фичу с изменением схемы БД, то она чаще всего быстренько вливается в мастер и дальше живётся как обычно. Если всё же приспичит менять схему и не вливать в мастер, то я просто создам отдельную временную базу и не буду париться ни с какими синхронизациями


Контроль структуры таблиц осуществляется через миграции в любой ORM, как уже отметили выше. Бэкапы же данных храниться в git не должны (максимум — небольшой набор фикстур для начальной инициализации свежесозданной БД). Так что всё это выглядит довольно бессмысленно


происходит 500-я и вы не знаете почему

Дык логи читать надо


Для того, чтобы соблюсти контроль версии базы данных используя гит, очевидно нужно получать ее дампы

Не нужно, потому что миграции всё контролируют сами

При хранении дампа БД в Git есть проблема нещадного разрастания размера коммитов, если сама БД довольно большая (например, в случае рабочего сайта с CMS).
А если скрипт упаковать, то он будет хранится обычным бинарным файлом.
Есть такое, но если правильно настроить конфиг размер будет сильно уменьшен.
Согласен со всеми кто против такого подхода. За маленьким исключением. Существует достаточно специфический класс сайтов это типа визитка без контента типа новостная лента и т.п. то есть практически статика. Но при разработке юзается cms с хранением в базе данных. Да там хранить дампы в git вполне допустимо т.к. ещё раз повторю это практически статика.
Автор намекает что имеет дело именно с такими сайтами просто не акцентировал на этом внимание. Хотя этот момент очень важен исходя из такого нестандартного решения
Для таких сайтов достаточно единственного скрипта без какой либо интеграции с 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


Ну понятно что возможно автор не использует какой то Фреймворк типа yii2, laravel или Django. Но просто автор уж очень сильно уходит на «тёмную сторону», он и сразу пишет что исправления все на live сервере/сайте. То есть все как то уж очень по суровому. Если уж так все сурово сразу то зачем бекапы то тогда :)
Это не «тёмная сторона», там совсем нет печенек, только сухари
тут не про версионирование структуры бд, а про версионирования содержимого. Если я правильно понимаю в django для этого есть django-reversion
Я прекрасно понимаю, что есть миграции, и знаю что делать когда есть 500 итд, но помимо yii2, laravel или Django итд существует 100500 CMS и самописных монстров, которые развиваются небольшими командами и постепенно перемещаются в пекло из-за гуанокодеров и развития технологий. Правильная настройка конфига позволяет сохранять только структуру без содержимого, тогда рост минимален в таком случае, а что уж с ней делать потом это второй вопрос. Я думаю что если разраб будет пользоваться снимками структуры, то он прекрасно знает как этот вопрос решить.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.