Механизм контроля версий базы данных в GIT (управление дампами MySQL)

[questor]

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

[setest1]

Да верно, отчасти это была тренировка в баше )

[smarthomeblog]

Если речь идет о разработке, к примеру, веб приложения, то да — миграции наше все. Как насчет приложений, которые базируются исключительно на базе данных. К примеру, разнообразные бизнес аналитические тулзы. По факту, там имеется одна, а то и несколько баз данных с кучей таблиц, триггеров и хранимых процедур. Данные туда приходят из разных источников. Отчеты генерятся специальной тулзой. И тут встает вполне резонный вопрос. Как сделать, что бы структура базы с триггерами и процедурами, лежала в гите, и было бы удобно редактировать, смотреть изменения, откатывать изменения админу баз данных.

[andreymal]

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

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

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

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

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

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

[rsashka]

При хранении дампа БД в Git есть проблема нещадного разрастания размера коммитов, если сама БД довольно большая (например, в случае рабочего сайта с CMS).
А если скрипт упаковать, то он будет хранится обычным бинарным файлом.

[setest1]

Есть такое, но если правильно настроить конфиг размер будет сильно уменьшен.

[Valsha]

Миграции? Нет, не слышали :)

[apapacy]

Согласен со всеми кто против такого подхода. За маленьким исключением. Существует достаточно специфический класс сайтов это типа визитка без контента типа новостная лента и т.п. то есть практически статика. Но при разработке юзается cms с хранением в базе данных. Да там хранить дампы в git вполне допустимо т.к. ещё раз повторю это практически статика.
Автор намекает что имеет дело именно с такими сайтами просто не акцентировал на этом внимание. Хотя этот момент очень важен исходя из такого нестандартного решения

[rsashka]

Для таких сайтов достаточно единственного скрипта без какой либо интеграции с 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

[Valsha]

Ну понятно что возможно автор не использует какой то Фреймворк типа yii2, laravel или Django. Но просто автор уж очень сильно уходит на «тёмную сторону», он и сразу пишет что исправления все на live сервере/сайте. То есть все как то уж очень по суровому. Если уж так все сурово сразу то зачем бекапы то тогда :)

[n0wheremany]

Это не «тёмная сторона», там совсем нет печенек, только сухари

[speker]

тут не про версионирование структуры бд, а про версионирования содержимого. Если я правильно понимаю в django для этого есть django-reversion

[setest1]

Я прекрасно понимаю, что есть миграции, и знаю что делать когда есть 500 итд, но помимо yii2, laravel или Django итд существует 100500 CMS и самописных монстров, которые развиваются небольшими командами и постепенно перемещаются в пекло из-за гуанокодеров и развития технологий. Правильная настройка конфига позволяет сохранять только структуру без содержимого, тогда рост минимален в таком случае, а что уж с ней делать потом это второй вопрос. Я думаю что если разраб будет пользоваться снимками структуры, то он прекрасно знает как этот вопрос решить.