Методология обновления базы данных - PullRequest
1 голос
/ 26 августа 2011

Как правило, схема базы данных будет меняться со временем. Между сборками может произойти от нуля до многих изменений схемы. Что такое «наилучшая практика» для фиксации этих изменений?

Например, скажем, 2 разработчика работают над проектом и используют git для контроля версий. Они соглашаются на сборку в пятницу. Каждый выполняет свою работу, проверяя изменения с помощью сценариев миграции баз данных, которые обновляются до текущей схемы. Когда человек А получает изменения человека Б, как они могут легко узнать, какие сценарии обновления нужно запустить? Когда человек просматривает базу данных на сервере, как он может узнать, в какой версии он находится? Если база данных фиксирует номер версии, это означает, что в пятницу один из сотрудников команды должен был сказать всем остальным: «Хорошо, все регистрируются, тогда я напишу сценарий, который обновит номер версии до следующего». версия и проверьте это. "

Есть ли стандартный подход к этому? Спасибо.

1 Ответ

1 голос
/ 29 августа 2011

Рассмотрите возможность записи одной миграции на изменение базы данных [структуры], а не на стабильную версию вашей системы.Точно так же, как ревизии кода: каждое изменение обновляет систему и увеличивает ее ревизию (не версию).

Обычно мы храним ревизию базы данных (вместе с «публичной» версией) в специальной таблице.Иногда мы храним имена сценариев миграции, которые были применены к этой базе данных, но это более сложное решение.Удобно включить ревизию базы данных, которая будет после применения миграции в имени файла.Последняя строка в скрипте миграции обновляет версию миграции в специальной таблице.

Чтобы определить, какие миграции применить к конкретной базе данных разработчика, вы просто берете все миграции, которые имеют более высокий номер редакции, чем версия базы данных, которая хранится в специальной таблице.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...