Essere nello spazio versione del database di controllo per 5 anni (in qualità di direttore del product management di DBmaestro) e dopo aver lavorato come DBA per oltre due decenni, vi posso dire il semplice fatto che non è possibile trattare gli oggetti di database, come si tratta il tuo Java, C# o altri file e salva le modifiche in semplici script DDL.
Ci sono molte ragioni e io vi citarne alcuni:
- I file vengono memorizzati localmente sul PC dello sviluppatore e il cambio s/he marche non influenzano altri sviluppatori. Allo stesso modo, lo sviluppatore non è interessato dalle modifiche apportate dal suo collega. Nel database questo è (di solito) non è il caso e gli sviluppatori condividono lo stesso ambiente di database , quindi qualsiasi modifica che è stata commessa al database riguarda gli altri .
- Le modifiche al codice di pubblicazione vengono eseguite utilizzando le modifiche di Check-In/Submit/ ecc. (A seconda dello strumento di controllo del codice sorgente utilizzato). A quel punto, il codice dalla directory locale dello sviluppatore viene inserito in il repository di controllo del codice sorgente. Lo sviluppatore che vuole ottenere l'ultimo codice deve richiederlo dallo strumento di controllo del codice sorgente. Nel database la modifica esiste già e influisce su altri dati anche se non era registrato nel repository.
- Durante il file del check-in, lo strumento di controllo di origine esegue un controllo dei conflitti per vedere se lo stesso file è stato modificato e il check-in da un altro sviluppatore durante il tempo si è modificato la copia locale. Anche in questo caso lo non è un controllo per questo nel database. Se modifichi una procedura da sul tuo PC locale e contemporaneamente modifico la stessa procedura con il codice dal mio PC locale, allora sostituiremo le modifiche l'uno dell'altro.
- Il processo di generazione del codice viene eseguito ottenendo l'etichetta/ultima versione del codice in una directory vuota e quindi eseguendo una compilazione - compilazione.L'output è binari in cui copia & sostituire lo esistente. Non ci importa cosa fosse prima. Nel database non possiamo ricreare il database in quanto abbiamo bisogno di mantenere i dati! Anche la distribuzione esegue script SQL che sono stati generati nel processo di build .
- Quando si eseguono gli script SQL (con i comandi DDL, DCL, DML (per comandi statici )) si presuppone che la struttura corrente dell'ambiente corrisponda alla struttura quando si creano gli script. In caso contrario, lo script potrebbe non riuscire mentre si sta tentando di aggiungere una nuova colonna che esiste già .
- Trattare script SQL come codice e generando manualmente causerà errori di sintassi, efficienti dipendenze errori, script che non riutilizzabili che complicano il compito di sviluppare, mantenere, testare tali script. Inoltre, tali script possono essere eseguiti su un ambiente diverso da quello per il quale si eseguirà .
- A volte lo script nel repository di controllo versione non corrisponde a la struttura dell'oggetto che è stato testato e quindi gli errori saranno in produzione!
Ce ne sono molti altri, ma penso che tu abbia ottenuto l'immagine.
Quello che ho trovato che funziona è la seguente:
- Utilizzare un sistema di controllo versione vigente che impone operazioni check-out/check-in sugli oggetti di database. Questo sarà assicurarsi che il repository di controllo versione corrisponda al codice che era registrato mentre legge i metadati dell'oggetto nell'operazione di check-in e non come un passaggio separato fatto manualmente. Ciò consente inoltre a diversi sviluppatori di lavorare in parallelo sullo stesso database mentre impedisce loro di ignorare accidentalmente l'altro codice.
- Utilizzare un'analisi di impatto che utilizzano linee di base come parte del confronto per identificare i conflitti e identificare se la differenza (se confrontando la struttura dell'oggetto tra il repository di controllo del codice sorgente e il database) è un vero e proprio cambiamento che origine da sviluppo o una differenza originata da un diverso percorso e quindi dovrebbe essere saltata, ad esempio un ramo diverso o una correzione di emergenza .
- Utilizzare una soluzione che sappia eseguire Analisi degli impatti per molti schemi contemporaneamente, utilizzando l'interfaccia utente o l'utilizzo dell'API per poter eventualmente automatizzare il processo di creazione di build.
Un articolo che ho scritto su questo è stato pubblicato here, siete invitati a leggerlo.
@marc_s Grazie per aver corretto l'errore di battitura. – Souper