In che modo i sistemi di controllo delle versioni di DB mancano nella semantica degli script se modellati su confronti di differenze origine / destinazione

0

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?

    
posta Mackers 22.07.2016 - 21:06
fonte

1 risposta

1

L'eliminazione della colonna rimuoverà tutti i valori da tutte le righe della tabella. Se la modifica si applica a tutte le righe che potrebbero essere nel database, ciò potrebbe essere accettabile. Se le tabelle modello sono per un set di base di record, è possibile che DROP COLUMN faccia cadere dati da altri record.

Il DDL (Data Definition Language):

ALTER table DROP COLUMN re_added_column;
ALTER table ADD COLUMN re_added_column;

È in qualche modo equivalente al DML (Data Manipulation Language):

UPDATE table SET re_added_column = null;

Tuttavia, la soluzione DDL sposta la colonna alla fine della riga. Questa posizione della colonna potrebbe essere non ottimale. La soluzione DDL può anche richiedere la rimozione e la ricreazione di indici e vincoli.

    
risposta data 24.07.2016 - 21:02
fonte