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

S>Почему же? Вполне себе срабатывает — мы "прикладной" код так и так рефакторим. А дальше остаётся вопрос: а с данными что делать?

Так в том и фишка документных БД что данные это и есть код

S>Совершенно верно. Я привёл вам пример "правила конверсии" v1 в v2, только очень убогого. Да, кстати, вы всегда добавляете в объекты, хранимые в монге поле "версия схемы документа"?

Разумеется, в этом суть версионирования и состоит. В РСУБД обычно где-то есть костыльная табличка с номерами версий, а тут версия есть у объектов, а не у хранилища в целом. Думаю, преимущества версионирования объектов перед версионированием всего хранилища подхода достаточно очевидны, чтобы их перечислять.

S>Если вы сели делать миграцию, то вы делаете миграцию. Единственная разница в РСУБД и NoSQL — это в том, что первая бьёт вас по рукам за попытки сделать миграцию неверно. Неопытные разработчики на это обижаются.

Это не миграция, а конверсия. Тут есть существенная разница, миграция подразуменвает что мы меняем данные, а конверсия что мы меняем интерфейсы доступа к данным. И когда мы делаем конверсию, нам помогает вся мощь инструментов разработчика начиная от компилятора и заканчивая автотестами с помощью фаззеров.

S>Кстати, монга уже умеет многодокументные транзакции? Т.е. могу ли я сделать конверсию v1->v2 "на горячую", с гарантированной целостностью изменений?

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

S>Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
S>Особенно здорово, когда схема меняется не просто как "заменить author на author[]", а как "заменить book[i] на ObjectRef()".

На практике, достаточно быстро появляет политика версионирования. "Поддерживаем последние 2 версии, в течение месяца после релиза в фоновом режиме конвертируем v1 в v2, в следующем релизе выкашиваем v1 из кодовой базы".