Nonostante la restrizione, lo consiglierò. : -)
"interrompe le chiamate al DB fino al termine dell'aggiornamento"
La modifica dello schema finirà probabilmente in pochi secondi (testalo su una copia di prova del database!), così gli utenti non noteranno nemmeno la pausa. La parte in pausa può essere implementata su un proxy in modo che non sia necessario apportare modifiche alle applicazioni. Ciò consente di modificare contemporaneamente il codice dell'applicazione in modo che non debba mai supportare contemporaneamente entrambe le versioni dello schema.
Supponiamo che tutti gli URL nella tua applicazione possano essere classificati come veloci (meno di 10 secondi) o lenti (10-60 secondi).
1) Il proxy inizia a mettere in pausa tutte le richieste lente e ad attendere 10-60 secondi per le richieste lente già in corso.
2) Il proxy inizia a sospendere tutte le richieste e attende 0-10 secondi per le richieste veloci già in corso.
3) Eseguire la migrazione dello schema e passare al nuovo codice applicazione che utilizza la nuova versione dello schema. Senza carico sul database, la migrazione dello schema dovrebbe essere molto veloce.
4) Il proxy consente a tutte le richieste messe in pausa.
Gli utenti che stavano aspettando richieste lente non sono sorpresi che le loro richieste in genere di 60 secondi richiedevano invece 130 secondi. Gli utenti che stavano aspettando richieste veloci potrebbero notare che la loro richiesta di 10 secondi richiedeva invece 30 secondi. Chiunque notasse il leggero ritardo probabilmente si dimenticherà un minuto più tardi.