Как организовать хранение последних изменений в БД проекта?

Question

[xSkyFoXx]

Нас 3 группы и мы все вместе делаем некоторые изменения в БД нашего проекта. Изменения делаются редко. Ничего не удаляют, а только добавляют таблицы и столбики в существующие. Но всё равно проблема, как-то трекать изменения. Никак не могу придумать, как бы сделать это в удобном виде.

Пробовал через файлик в репе, но совсем неудобно. А как вы решаете эту проблему? Может есть какие-то более удобные средства контроля версий и дифов для структуры БД?

Answer 1

[avalak]

Используйте миграции.

Answer 2

[sergei-grigorev]

Попробуйте CASE-средства, например Sybase PowerDesigner. Мы описываем модель БД, а затем генерируем sql-код для создания таблиц (есть функции обновления существующих БД). А чтобы все были в курсе изменений — на папку с моделями повесили оповещение. Как только кто-нибудь из разработчиков обновил модель — всем приходит оповещение по E-mail, с описанием того, что было обновлено. В итоге у нас всегда есть история изменений + диаграмма прямо перед глазами.

Answer 3

[Snowindy]

Одно из отраслевых решений для миграции БД.
Не идеальное, есть некоторые шороховатости, не удобно мигрировать данные…

Но это лучше чем без него
www.liquibase.org/

Answer 4

[1nd1go]

code.google.com/p/flyway/ — хороший тул, а главное концепция.

Мы в частности сначала сами делали файлики типа
01.init_tables.sql
02.add_one_table.sql
03.add_another.JIRA-1251.sql

Так и трэкали. Flyway делает многгое за вас, в частности делает метатаблицу, где отражает изменения и показывает текущую версию схемы.

Answer 5

[Shedal]

Я по этому поводу когда-то большую фундаментальную статью написал, с рассмотрением разных подходов. Ознакомьтесь, если хотите: habrahabr.ru/post/121265/

Answer 6

[RedQuark]

Мой личный велосипед основан на ссылка. Это намного удобней одного большого файла плюс SVN. Можно сильно усложнить велосипед, добавив в скрипты комментарии с ключами указывающие на авторство, что бы это как то обыгрывалось. Но увы, велосипеды обычно удовлетворяют потребности только автора.

Answer 7

[stepio]

1. Разбейте всю БД на отдельные сущности
2. Определите стиль форматирования, например здесь:
www.dpriver.com/pp/sqlformat.htm
3. Git

Comments

[stepio]

В результате под каждый объект БД получится отдельный .sql файл. Также можно разбить их на директории (по типу сущностей, например).

Плюс не забудьте также создать вызывающий скрипт, который опишет последовательность «дерганья» этих скриптов.

Плюсы: наглядность (одна сущность — один файл), все изменения локализированы (сразу видно кто какую сущность трогал), благодаря единому форматированию нет проблем с мерджем веток и прочим.
Минусы: вначале надо не полениться это сделать.

Подобный подход точно работает для Oracle (SQL*Plus отлично «последовательности файлов»). Но и для других БД я уверен это реально — сбацать какой-нибудь хитрый bash-скрипт, например, который будет меняться только при добавлении новых сущностей.

Answer 8

[MuXaJIbI4]

мы этим пользуемся http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/reference/introduction.html