Come versioni / traccia le modifiche alle tabelle SQL?

Uso uno strumento di migrazione del database basato su codice e mantieni il codice di migrazione nel controllo del codice sorgente.

Usando i timestamp come numeri di versione, qualsiasi numero di sviluppatori è per lo più libero di aggiungere migrazioni a loro piacimento e possiamo eseguire con sicurezza lo strumento di migrazione su qualsiasi copia del nostro database.

Usavo gli script SQL sotto il controllo della versione, ma trovo che l'approccio basato sul codice sia molto, molto più facile da usare perché tutti sono in uno "spot" logico e sono in grado di eseguire tutti gli script necessari con un singolo comando .

Non lo faccio da solo, ma alcuni sviluppatori mantengono una raccolta di script SQL sotto il controllo del codice sorgente che, una volta eseguito, può ricreare le tabelle del database a scopo di test e creare un database vuoto per scopi di produzione.

La stessa tecnica può essere utilizzata per eseguire la versione del database sul sito del cliente, quando è necessario aggiungere o rimuovere campi o tabelle oppure devono essere eseguite trasformazioni di dati.

Crea script sotto controllo di versione e integrazione continua per verificarli

Un approccio che ha funzionato per me consisteva nel far lavorare ciascuno sviluppatore con il proprio schema, in modo che potesse fare ciò che voleva. Il loro schema era distruttibile e popolato con dati di test presi da una serie di script controllati dalla versione a cui tutti gli sviluppatori hanno contribuito.

La build di integrazione continua notturna ha preso l'ultima versione di tutti gli script e ha tentato di creare un database di test coesivo da loro. L'applicazione ha quindi eseguito una serie di test di integrazione e funzionali per verificare che lo schema corrente fosse in linea con il candidato di rilascio corrente.

Prima di iniziare questa strada, c'era un progetto di database piuttosto solido e un DBA teneva sempre sott'occhio le cose per impedire agli sviluppatori di impazzire con denormalizzazione e altri orrori.

Il controllo della versione ha aiutato immensamente qui perché le modifiche agli script erano immediatamente evidenti. Abbiamo anche utilizzato una tabella di database VERSION per identificare lo stato generale del database. Questa era una semplice sequenza intera e non era collegata a nessuna particolare applicazione.

Nel complesso, ha funzionato bene e ha impedito agli sviluppatori di avere paura di modificare i livelli di persistenza perché potevano sempre ripristinare i propri schemi senza influire sugli altri.

Se sei in un negozio di MS, Visual Studio 2010 ha alcuni strumenti di controllo della versione del database, che possono anche generare script di modifica / distribuzione in base alle differenze tra due database.

Oltre a mantenere schemi e altri script SQL sotto controllo di versione, un'altra pratica pratica è mantiene una tabella 'versione schema' nel DB attuale .

create table schema_migrations (
    'appliedAt' timestamp not null default CURRENT_TIMESTAMP,
    'migrationCode' varchar(256) not null,
    'extraNotes' varchar(256),
    primary key ('migrationCode')
)

Doctrine ha uno straordinario strumento di migrazione: link , la parte migliore è che sono autogenerato o può essere facilmente codificato a mano.

L'approccio che utilizzo è fornire una tabella per i parametri. Questa tabella avrà una coppia nome / valore per la versione su cui si trova il database. Questo mi dà due vantaggi: ho un modo di verificare che solo una correzione del database è stata applicata attraverso l'applicazione e posso usare quel valore per i miei script SQL.

Lo script SQL creerà nuove tabelle, modificherà colonne e qualsiasi lavoro necessario sul database per promuovere lo script dalla versione precedente. Idealmente avrei anche uno script di rollback, ma il più delle volte no.

A proposito, l'intero approccio è stato automatizzato come parte di Ruby on Rails, completo degli script di rollback. Mi piace l'idea, ma non tutti i framework lo fanno. Quando non utilizzo Ruby on Rails, utilizzo l'approccio descritto sopra.