Управление версиями базы данных всегда самая сложная вещь в среде с несколькими разработчиками.
Обычно каждый пользователь имеет свою собственную БД, которая является химерой некоторых, но не всех изменений БД. Когда они вносят изменения, им нужно будет зафиксировать свои сценарии изменений. Это становится действительно неловким. Основные проблемы, как представляется, связаны с изменениями базы данных, затрагивающими многие аспекты системы, а также с несколькими изменениями таблиц, зависящими друг от друга, а также с тем, как перейти на новую схему из старой схемы. Перенос данных в новую схему обычно нетривиален. Часто вы хотите по умолчанию столбец, когда данные копируются в новую схему, но НЕ по умолчанию, скажем, столбец по умолчанию для INSERT. Как правило, они уже сложны в вопросах производственного развертывания, и им приходится управлять базой данных во время разработки, когда проектирование базы данных может происходить так же быстро, как и основное развертывание, - это гораздо больше работы, чем обычно требуется при разработке. Время, которое лучше потратить, чтобы убедиться, что ваша база данных хорошо спроектирована - ограничения, внешние ключи и т. Д.
Поскольку разработчики с большей вероятностью наступают друг на друга с изменениями в базе данных, у нас всегда была точка доступа к базе данных - все разработчики разработали против той же самой базы данных разработки и сделали свои изменения «живыми». Затем база данных dev контролировалась версией независимо. Это не очень легко, когда люди находятся вне офиса или что-то в этом роде. Другая альтернатива - назначить разработчиков баз данных, которые координируют изменения, необходимые нескольким разработчикам, в одной таблице - это не обязательно должно быть всей их работой, но обеспечивает лучшую согласованность дизайна БД. Или вы можете координировать ревизии базы данных, чтобы люди больше знали о ревизиях БД, которые делают другие люди, и планировали свои изменения, чтобы дождаться, когда ревизия БД станет доступной от другого разработчика.