Система контроля версии для баз данных

[gauss_gauss]

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

 

[Black Hat]

Есть несколько вариантов и все "плохи" в том или ином виде.
Что приходилось реально использовать
- "внутреннюю" утилиту, которая брала XML (под управлением гита) и выдавала DDL
- mysqldump можно запустить с ключиком --no-data плюс добавить еще несколько, и на выходе DDL, который также можно хранить вместе с кодом в гите
- ... есть и много других решений (гугл)

 

[DeaDSandro]

Для просмотра ссылки Войди или Зарегистрируйся
Миграции сейчас есть во многих популярных фреймворках или например в Doctrine (PHP) из коробки

 

[gauss_gauss]

Для просмотра ссылки Войди или Зарегистрируйся
Миграции сейчас есть во многих популярных фреймворках или например в Doctrine (PHP) из коробки

Читал эту статью . Мне бы хотелось услышать реальный опыт, кто что в проектах применяет

 

[kto-to]

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

 

[lgtch]

Для актуализации БД в проектах применяются миграции. Реализованы в любом фреймворке и даже в некоторых CMS.

Работает так - пишите руками скрипт для выполнения sql-запроса к вашей БД, запускаете скрипт (он делает нужные вам изменения в вашей локальной БД), коммитите его в репозиторий, другие разработчики вытаскивают ваш коммит со скриптом и применяют его, профит)

Читал эту статью . Мне бы хотелось услышать реальный опыт, кто что в проектах применяет

За долгие год работы в команде над большими проектами убедился в эффективности и полезности этого подхода.

 

[HunterNNm]

Во всех проектах, где нет фреймворка, пользуем Для просмотра ссылки Войди или Зарегистрируйся . И Вам советуем Мощный инструмент...

 

[tuthanhamon]

Если кратко - есть набор скриптов (файлов вида database####.sql). Файл database_0000.sql был создан когда было принято решение о том, что "в лесу порядок должен быть"©. Любые последующие изменения базы данных - это файл database0001.sql, 0002.sql и так далее, в котором описано все что надо изменить в базе чтобы она соответствовала эталону: добавить/удалить таблицы, изменить данные, добавить комментарии и т.д. В конце каждого файла есть строка вида

insert into database_log(version, changes, note) values (2, 'Добавили новое поле для хранения истории статусов', 'Для всех пользователей в историю записано "Молодец" как маркер начала истории');

Все эти файлы хранятся в репозитории git-a.
В результате в любой момент можно получить базу данных любой версии, или посмотреть прямо в базе что, когда и почему менялось.
Потенциальная проблема только одна - если над базой работает очень много народу, надо контролировать, чтобы случайно двое разработчиков не закоммитили разные скрипты с одинаковым названием. Но это - типичная проблема в больших коммандах и методики решения стандартные: конвенция наименований, код-ревью, ответственный за коммиты и т.п.

 

[Bezhev]

Читал эту статью . Мне бы хотелось услышать реальный опыт, кто что в проектах применяет

Применются миграции, пользовался Doctrine migrations и Phinx, и еще doctrine fixtures для накидыванию тестовых данных.

 

[nick dee]

Должен прочитать Получить базу данных под управлением версиями. Проверьте ряд должностей К. Скотт Аллен .