Я нахожусь в лагере "одна база данных разработки".
В отличие от традиционного исходного кода ОО, в базе данных часто собираются таблицы, поддерживающие функции нескольких пользователей.Когда несколько разработчиков собираются внести аналогичные изменения, вы можете попросить их отработать это заранее или попытаться синхронизировать два сценария сборки.Проблема со сценариями сборки и миграциями заключается в том, что большинство ситуаций нетривиальны.Хотите отключить NULL в БД?- вам нужно решить, к каким данным следует применить по умолчанию, и должны ли данные заполняться из других источников.Нужно провести рефакторинг, чтобы нормализовать таблицу на две части?- вам нужно решить, как назначить ключи.И затем, когда два пользователя вносят изменения в одну и ту же таблицу ...
Это не значит, что она не должна находиться под контролем исходного кода, потому что она должна.
В конечном итоге, поскольку у вас больше разработчикови больше каналов связи: вы хотите, чтобы изменения базы данных проходили через администратора базы данных - это позволяет координировать изменения и избегает многих проблем с каналами связи в команде - это превращает каналы связи в звезду.
Кроме того, если вы ограничиваете себя программированием с использованием явного слоя служб баз данных, такого как представления и хранимые процессы, разработчики приложений будут хорошо защищены от изменений базы данных и рефакторинга.
Через определенное времяВ процессе разработки изменения базы данных становятся довольно управляемыми, поскольку изменений в базовой схеме базовой таблицы меньше (хотя представления и хранимые процедуры могут оставаться нестабильными).