__MichelleТогда нужно будет заботиться о поддерживании этого "нулевого" экземпляра в актуальном состоянии,
то есть повторять в нем все последующие возможные изменения структуры.

Я именно так и делаю... (к счастью...) пока это самое эффективное решение с точки зрения уйти от попадалова и заработать дополнительно...
- Появляются новые режимы, влекут за собой новые поля, связи, иногда таблицы - делаю и на тестере и в эталоне...
- Потом начинается патч старых версий у клиентов на новые, выравниваю их структуру с эталоном...
- Делаю исключительно руками у всех или лично или по удаленке, за одно и смотрю состояние старой структуры
(основные связи) всем видно что я работаю и все понимают, что платят за обновление не зря, если у клиента версия древняя - доходит по времени до полу часа...
Вариант
__MichelleНаверное проще сделать механизм очистки и сжатия.
пару раз подводил - терялось один - два ключа или одна две связи - приложение выезжало исключительно
на сохраненных запросах, хотя и появлялись дополнительные тормоза... такие плюхи часто возникают если
механизм очистки и сжатия работает из приложения с прилинкованной БД, а у клиента сетка 100 и перегружена, на сервак никто никого не пускает, да и акес там даже не стоит...

Короче, если бы у меня был механизм указать пустую базу (эталон) и рабочую (для патча) и сказать фас -
то я бы не сильно то и обрадовался... иногда при добавлении поля или флага в таблицу нужно еще и всем
существующим записям прописать в новое поле значение - иначе этот патч не имеет смысла...

В общем всё мутно и не однозначно (нужны эти механизмы (авто патчей) вообще или нет) наверное не помешали бы.... а так :
-Новый клиент скачивает и устанавливает последний дистрибутив, в котором гарантированно лежит последний пустой эталон...
- старым клиентам (мне лично) удобно делать всё руками и брать за это деньги...
Ну в общем за отсутствием (у меня того что просит ТС) делаю как говорит __Michelle и особо не страдаю...