Да, я думал об этом. Но тут все равно возникают проблемы с table changes - некоторые изменения нужно выполнять в строгой последовательности. И это привязывает нас либо к одной базе, либо к строгой дисциплине. Последнее обладает свойством время от времени ломаться. Если при этом будет ломаться (а время от времени так и будет) нормальный ход работы - то это большая проблема. Так что мы приходим к варианту с одной базой данных. А следовательно нужна возможность брать сущности базы на уникальное пользование (лочить проще говоря). Поэтому получив пару шишек от грабель ищу средство убирающее грабли или хотя бы поролонновую насадку на ручку грабель...
Тогда возможно нужен иной подход. Задача руководителя проекта дать как можно более независимые участки задачи разработчикам, такие чтобы не было необходимости изменять один и тот же объект, таблицу по сути.
Понимаю, что это не всегда возможно, тогда, по-моему, хорош подход при котором каждый разработчик, после того как завершит определённую часть, выкладывает migrate скрипт. Тогда для получения определённой версии БД (или таблицы БД) нужно последовательно выполнять эти скрипты.
Есть даже средства для автоматизации такого подхода. То есть скрипты автоматически запускаются и в точности в той последовательности чтобы получить заданную версию БД.
А одна база не будет удобна ни для тестирования, ни для разработки, опять же проблемы при изменении данных и структуры, проблемы с целостностью...
Данное сообщение получено с сайта GotDotNet.RU
|