Non sono un esperto di questo settore, ma sono consapevole che esistono già soluzioni per la gestione delle migrazioni dei database nel controllo della versione, ad es. sqitch e liquibase . Tuttavia attualmente sto pianificando un piccolo progetto per hobby e anche sqitch sembra un fastidioso ammontare di spese cognitive.
Idea
Una migrazione è un (nome, azione su, giù azione). Stavo pensando di mantenere una singola tabella di colonne (la tabella delle migrazioni ) nel database SQL contenente nomi univoci di tutte le migrazioni che erano state eseguite. Quindi nel codice sorgente controllato dalla versione ci sarebbe una lista (la lista delle migrazioni ) con l'ordine delle migrazioni da eseguire.
Pro:
-
I conflitti
- ( chiave ) nella lista delle migrazioni verrebbero rilevati dal software di controllo della versione, ad es. git, e poi risolto manualmente;
- un database può facilmente aggiornarsi eseguendo le migrazioni nella lista delle migrazioni che non si trovano nella tabella delle migrazioni nell'ordine in cui appaiono nella lista;
- un database di sviluppo può eseguire il rollback agli schemi precedenti eseguendo l'azione in giù per tutte le migrazioni nella tabella di migrazione che si verificano prima della migrazione di destinazione nella elenco delle migrazioni ( potrebbe essere necessario aggiungere un timestamp in modo che possano essere rimossi nell'ordine corretto);
- è abbastanza semplice che io stia bene con la scrittura di un'implementazione ad-hoc per un progetto.
Contro:
- l'ovvia critica xkcd ;
- forse qualcuno l'ha già fatto e non ha funzionato;
- forse nessuno lo ha fatto prima perché non funzionerà.
Domanda
Quindi la mia domanda è, dato che voglio gestire le migrazioni dello schema nel controllo di versione ma non voglio complicare le cose, la soluzione di cui sopra è una buona idea? Sono aperto ad altre soluzioni se sono in grado di rilevare o risolvere automaticamente i conflitti di migrazione e sono semplici.