Имею привычку хранить в сурсконтроле не только код приложения, но и базы, разбитый на файлы по таблицам БД. Т.е. каждая таблица в своем файле.
Это очень удобно:
- во-первых, база "эволюционирует" одномоментно с кодом (одним ченжсетом фиксируется) - нет проблемы, понять какая база нужна для той или иной "исторической" версии сырцов,
- во-вторых, т.к. база разбита по-элементно, меньше "букв" для сопоставления изменений базы и кода
Минусы и как с ними бороться:
- геморройно "апгрейдить" базу полностью пересоздавая таблицы, потом опять данными заполнять...
Специально для этого я веду папочку "patches", которая содержит alter/create/drop-скрипты - если выполнить их последовательно, то база будет эволюционировать от одного ченжсета к другому. Эти скрипты пишутся вручную, и часто учитывают фишки с целостностью по ключам, уникальными индексами и т.п.
- база из кусков, геморройно запускать кучу файлов для создания
Пишем скриптик, который соберет ее в один файл (см. ниже)
Ну и пример реализации для mysql
.
по-табличный дамп базы:
#!/bin/bash
basedir='./'
table_struct_dir="$basedir/tables"
table_data_dir="$basedir/data"
db=rnet_reports
dbuser=root
dumpopt='--compact -u$dbuser $db'
tables=`echo 'show tables;' | mysql -N -u$dbuser $db`
mkdir -p $table_struct_dir
mkdir -p $table_data_dir
echo 'Dumping tables:'
for tab in $tables; do
echo ' ' $tab
mysqldump $dumpopt -d $tab | grep -v '^[/\*]' > $table_struct_dir/$tab.sql
done;
echo
echo "all done."
echo
сборка скрипта
#!/bin/bash
fname='dump.sql'
fdir='./tables/'
touch $fname
for f in `ls $fdir`; do
cat $fdir$f>>$fname
done;
PS Недолюбливаю mysql, но в последнее время приходится часто иметь с ним дело. В основном это всякая мелочевка, не превышающая возможности 4-ой ветки, а часто и даже 3-ей: 5-10 MyISAM табличек. Так что, врятли я буду доводить до ума этот скрипт. AS IS.
upd: исправление в скрипте дампа