Esistono diverse soluzioni per il controllo delle versioni del database disponibili per aiutare a controllare non solo il controllo delle versioni di un database, ma anche la distribuzione e la sincronizzazione dei database. Questi sistemi sono tipicamente basati su un modello di "sincronizzazione sorgente / target di destinazione" o su un modello di "applicazione diretta di script di migrazione". La mia domanda riguarda il modello di sincronizzazione delle differenze sorgente / target.
In questo modello, si esegue essenzialmente un'istantanea di un database di origine (la base del record) e si esegue un confronto di questa istantanea con un database di destinazione. Lo strumento creerà idealmente gli script necessari per sincronizzare il database di destinazione per avere la stessa struttura (e dati di riferimento) del database di origine. Uno degli svantaggi di questo modello è che lo strumento potrebbe non essere abbastanza intelligente da catturare la semantica esatta delle modifiche al database che sono state apportate e creerà script "cattivi".
Ci sono dei buoni esempi di cosa sia uno script "cattivo"? Non riesco a capire perché questo sia uno svantaggio. Ad esempio, se si rilascia una colonna su una tabella di dati di riferimento e quindi la si aggiunge nuovamente, si finisce con una tabella con la stessa struttura, ma con valore null (o valori predefiniti) nella colonna riaggiunta. Uno strumento di sincronizzazione potrebbe generare qualcosa come:
UPDATE table SET re_added_column = null where pk_column = <val_1>;
...
UPDATE table SET re_added_column = null where pk_column = <val_n>;
Mentre il seguente potrebbe essere più efficiente (e rappresenta esattamente quello che è successo):
ALTER table DROP COLUMN re_added_column;
ALTER table ADD COLUMN re_added_column;
Nell'esempio, tuttavia, non riesco a capire perché questa differenza sia una vera causa di preoccupazione. È solo che il primo è "più sporco?" Ci sono degli esempi in cui ci sarebbe un problema EFFETTIVO con questo comportamento?