Gestione delle modifiche allo schema del database quando si inseriscono nuove versioni

Automatizzare. Automatizzare. Automatizzare.

Sei sulla strada giusta con un numero di versione DB esplicito, ma farei un ulteriore passo avanti e rendere il codice esplicitamente a conoscenza esattamente dello schema su cui si aspetta di lavorare (ad esempio, impegnando l'effettivo script DDL e avendo il updater lo analizza); quindi al momento dell'aggiornamento devi solo scoprire lo schema esistente tramite i metadati del database e INSERT / DROP / ALTER se necessario, indipendentemente dalla versione della versione che stai aggiornando. (È inoltre possibile mantenere un numero di versione esplicito nel database stesso e consegnare l'intera cronologia dello schema con il programma di installazione in modo che non sia nemmeno necessario il rilevamento dello schema.)

Potenziali errori di sintassi nello script SQL di aggiornamento sono un problema, ma è possibile risolverlo verificando che l'updater possa produrre solo istruzioni DDL corrette. (Le prove formali non sono quasi mai utili nello sviluppo del software aziendale - troppo sforzo per troppa poca sicurezza - ma ritengo che l'integrità del database sia una delle poche eccezioni: l'SQL di base non è un linguaggio particolarmente difficile da catturare formalmente, e il beneficio di proteggere i dati di produzione è così grande che è giustificato quasi ogni sforzo iniziale di una volta, in particolare se deve funzionare per installazioni non presidiate,)

Il versioning dello schema del database è la strada da percorrere: ogni versione ha una sola modifica al database, o almeno modifiche che possono essere ripristinate nel loro complesso. DBDeploy è un ottimo strumento per automatizzarlo.

Alcune cose che ho imparato utili sono:

1. Sempre verifica la tua modifica a livello locale e prova il tuo codice con esso, solo il ALTER di passaggi non è sufficiente
2. Devi sincronizzare quali sono i primi a fare i loro cambiamenti - una semplice pagina wiki in cui puoi "prendere un numero" ha funzionato alla grande per il mio team.
3. Non cercare di correggere le modifiche non funzionanti, aggiungi un nuovo contromovimento per annullarlo, è molto più semplice
4. Il tuo codice dipende da queste modifiche: assicurati di collegare i problemi nel tuo sistema di tracciamento dei bug con le modifiche al DB. È molto utile al momento della distribuzione.
5. Includi modifiche DB all'elemento della configurazione - applica le modifiche a un database dell'elemento della configurazione su commit. Inoltre, se hai dei test che usano un database, eseguili su commit.

Dato che stai usando phpMyAdmin, suppongo che tu stia usando anche MySQL.

Dai un'occhiata ai diagrammi di EER Model in MySQL Workbench. Sono stati di grande aiuto per mantenere e aggiornare gli schemi.

In primo luogo, è possibile sincronizzare il modello con un'origine del database. In questo modo le modifiche nel diagramma vengono inviate come comandi ALTER TABLE. Ciò consente di eseguire le modifiche dello schema nel diagramma, tenerlo sempre aggiornato e, se necessario, anche di inviare aggiornamenti al database di sviluppo.

In secondo luogo, è possibile decodificare un diagramma EER da una sorgente di database. Che può essere utile apportando modifiche a un database di sviluppo e aggiornando un database di produzione poiché calcola le differenze.

In terzo luogo, può essere usato per aiutare a creare l'SQL che dovrebbe andare nel tuo file "update.sql".

CONS:

I trigger e i vincoli del database sono un problema con l'updater di sincronizzazione. Non sembra conoscere l'ordine giusto delle cose. I vincoli di chiave esterna spesso generano errori, ma ciò può essere risolto modificando l'SQL generato.

Questo non è uno strumento di migrazione dei dati. Qualsiasi modifica che vada oltre lo schema avrà comunque bisogno di SQL personalizzato.

Dai un'occhiata al link - è una libreria di migrazioni DB per Django (un framework Python) ma:

1. puoi ottenere grandi idee da esso (e forse anche trovare un clone PHP)
2. puoi effettivamente usarlo indipendentemente dal resto di Django per gestire le tabelle dell'app PHP / MySQL.

Può anche generare script di aggiornamento dello schema; gestisce anche le inversioni del cambio automaticamente la maggior parte del tempo.