Lo scopo di un database è proprio quello di permetterti di mantenere le cose separate. Quindi mentre non devi, puoi.
Il requisito si riduce a ciò di cui hai bisogno, prendendo in considerazione quale sia il metodo migliore per risparmiare tempo ovunque sia pratico.
Ho lavorato su un sistema per il quale abbiamo completamente disaccoppiato le modifiche al database dalle modifiche alle applicazioni. Infatti, abbiamo fatto un punto di non fare entrambi contemporaneamente, a meno che non fosse necessario (o meno che l'intero punto del cambiamento dell'applicazione fosse quello di introdurre nuove funzionalità nel database). Il motivo per cui cercavo di non fare entrambe le cose contemporaneamente era di minimizzare i rischi di errori e di dover invertire l'installazione. Più cambi in una volta, più alto è il rischio. Ma quello era il controllo del traffico aereo, quindi siamo stati attenti. Tutto dipende dalle tue circostanze e dai requisiti dell'utente finale.
Il modo in cui abbiamo risolto il controllo delle versioni è che ogni versione del database è stata anche contrassegnata con la versione dell'applicazione. Le nostre versioni applicative erano tali che sapevamo semplicemente guardando i numeri di versione se il database era compatibile o meno (cioè le versioni principali erano modifiche DB, le versioni secondarie all'interno di una stessa versione principale erano tutte compatibili con DB). Non importa quale sia il tuo schema, ne hai bisogno uno di facile lettura e amp; pista.