Здравствуйте, Miroff, Вы писали:

M>>вы говорите что у разработчика на компе своя база?

M>Да, нет смысла на этом экономить. Если по какой-то причине не хочется держать базы на машине разработчиков, можно завести для каждого разработчика базу на общем сервере.

+1, у каждого разработчика на компе своя база.

M>>Вы версии баз как ведете? Привязываете к версии системы?

M>В базе табличка с номером актуальной версии, в приложении код, проверяющий что версия базы не меньше нужной. В зависимости от флага, приложение либо раскатывает миграции на базу, либо вообще не стартует и зовет админа. Когда хочешь поменять базу, пишешь миграцию и инкрементируешь номер версии. Многие системы версионирования БД устроены сходным образом, посмотрите на Liqubase или Flyway.

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

По такой схеме работает большинство инструментов которыми я пользовался по крайней мере.