Come si modificano / tengono traccia delle modifiche alle tabelle SQL?

Quando si lavora in un team di sviluppatori, in cui tutti stanno apportando modifiche alle tabelle locali e alle tabelle di sviluppo, come mantenere sincronizzate tutte le modifiche? Un file di registro centrale in cui tutti mantengono le loro modifiche sql? Una pagina wiki per tenere traccia delle istruzioni alter table, dei singoli file .sql che gli sviluppatori possono eseguire per portare i loro db locali all'ultima versione? Ho usato alcune di queste soluzioni e sto cercando di ottenere una buona soluzione solida che funzioni, quindi apprezzerei le tue idee.

Uso uno strumento di migrazione del database basato su codice e mantengo 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 lo strumento di migrazione contro qualsiasi copia del nostro database con fiducia.

Usavo gli script SQL sotto il controllo della versione, ma trovavo l'approccio basato sul codice molto, molto più facile da lavorare perché tutti si trovavano in un "punto" logico ed erano 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 eseguita, può ricreare le tabelle del database a scopo di test e creare un database vuoto a scopi di produzione.

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

Crea script sotto controllo versione e integrazione continua per verificarli

Un approccio che ha funzionato per me è stato quello di far lavorare ogni sviluppatore con il proprio schema con il quale possono fare ciò che gli piace. Il loro schema era distruttibile e popolato con dati di test tratti da una serie di script a versione controllata a cui hanno contribuito tutti gli sviluppatori.

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

Prima di intraprendere questa strada, era in atto una progettazione di database piuttosto solida e un DBA teneva sempre d'occhio le cose per impedire agli sviluppatori di impazzire con la denormalizzazione e altri orrori.

Il controllo della versione ha aiutato immensamente qui perché le modifiche agli script erano immediatamente ovvie. Abbiamo anche utilizzato una VERSIONtabella di database 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 significato che gli sviluppatori hanno smesso di temere di cambiare i livelli di persistenza perché potevano sempre ripristinare i propri schemi senza influire sugli altri.

Se ti trovi in ​​un negozio 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 gli schemi e altri script SQL sotto controllo della versione, un'altra pratica pratica è quella di mantenere una tabella di "versione dello schema" nel DB effettivo .

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

Doctrine ha un fantastico strumento di migrazione: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , la parte migliore è che sono autogenerati o possono essere facilmente codificati a mano.

L'approccio che uso è di fornire una tabella per i parametri. Questa tabella avrà una coppia nome / valore per la versione su cui si trova il database. Questo mi offre due vantaggi: ho la possibilità di verificare tramite l'applicazione l'applicazione di una sola correzione del database e posso usare quel valore per i miei script SQL.

Lo script SQL creerà nuove tabelle, modificherà le colonne e tutto il 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 di script di rollback. Mi piace l'idea, ma non tutti i framework lo fanno. Quando non sto usando Ruby on Rails, utilizzo l'approccio descritto sopra.