Come può un gruppo tenere traccia delle modifiche allo schema del database?

Quali metodologie di controllo della versione aiutano i team di persone a tenere traccia delle modifiche allo schema del database?

solo un paio di minuti fa stavo controllando questo: una tabella che dovrebbe esistere in tutti i progetti con un database , sembra abbastanza semplice da mettere in pratica, dai un'occhiata:

Si chiama schema_version (o migrazioni, o qualunque cosa ti piaccia) e il suo scopo è quello di tenere traccia delle modifiche strutturali o dei dati al database. Una possibile struttura (esempio in MySQL) è:

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

inserire in schema_version ( key, extra) i valori ('001', 'versione dello schema');

Sia che tu aggiunga questa tabella dall'inizio del progetto o subito dopo aver distribuito la prima versione su un server di gestione temporanea o di produzione, dipende da te.

Ogni volta che è necessario eseguire uno script SQL per modificare la struttura del database o eseguire una migrazione dei dati, è necessario aggiungere anche una riga in quella tabella. E farlo tramite un'istruzione insert all'inizio o alla fine di quello script (che è impegnata nel repository di codice del progetto).

...

Penso che il metodo migliore sia generare il database come parte del processo di compilazione . Mantieni tutti gli script nel controllo del codice sorgente con il resto del codice e ognuno è responsabile del proprio ambiente.

In caso contrario, RedGate ha uno strumento per integrare il controllo del codice sorgente in SSMS e SQL Compare è utile per confrontare / sincronizzare gli schemi di MS SQL Server. Visual Studio Database Edition ha anche uno strumento di confronto degli schemi integrato .

Un'altra domanda SO mi porta a Migrator Dot Net che inizierò a indagare durante il mio abbondante tempo libero. Sembra un buon metodo, ma potrebbe essere più di un investimento in termini di tempo / spese generali di quanto tu sia disposto a fare.

eiefai ha già menzionato Una tabella che dovrebbe esistere in tutti i progetti con un database . Questo è un ottimo post sul blog, ma IMO fa solo parte di una soluzione funzionante per il controllo di revisione del database. Penso che qualsiasi tentativo di "rispondere" a questa domanda nel mondo reale debba prendere in considerazione alcune delle altre informazioni su VCS e database:

• La metodologia dei dati agili
• Il libro "Database Refactoring"
• Articolo di Martin Fowler su "Progettazione di database evolutivi"
• Lo strumento Liquibase
• Un video decente con Scott Ambler che presenta i suoi pensieri su "Database Agile"

Ci sono un paio di angolazioni diverse per affrontare questa domanda, credo. L'angolo "primo strumento", credo, varierà in base alla piattaforma e alle preferenze personali. Caso in questione: sto usando un progetto di database in MS Visual Studio, ma non sono sicuro che questa sia un'ottima soluzione per MySQL. Conosco anche persone che sono abbastanza vendute sui loro strumenti preferiti da Redgate, Erwin, Embarcadero, ecc.

C'è anche un'angolazione "prima di tutto" per questa domanda, che (si spera) verrà rivisitata su questo sito nelle domande successive. Le pietre miliari di questo processo stanno mettendo il tuo schema sotto il controllo del codice sorgente e gestendo le modifiche in modo tale da poter applicare le modifiche dello schema dalla versione "x" alla versione "y" praticamente su richiesta.

Una risposta definitiva a questo argomento finirà per sembrare un libro, quindi probabilmente vale la pena iniziare facendo riferimento a uno: Redgate ha recentemente pubblicato un ebook gratuito chiamato " La guida di Red Gate allo sviluppo basato su team di SQL Server ", e mentre c'è molto da discutere, è un ottimo posto per iniziare a discutere, IMO. Contrariamente al nome, gran parte del materiale in questo libro è abbastanza generale da applicare a qualsiasi DB (non solo SQL Server) e qualsiasi set di strumenti (non solo Redgate). Se non l'hai già visto, vale sicuramente la pena scremare, almeno.

Infine, vale probabilmente la pena collegarlo nella "risposta legacy" di StackOverflow .

SchemaCrawler è il mio strumento per produrre un file di testo con tutti gli oggetti dello schema del database. Ho progettato questo output di testo in modo che sia leggibile dall'uomo, oltre che diffondibile da un output simile di un altro server.

In pratica, quello che ho scoperto è che l'output di un file di testo dello schema del database è utile, se fatto come parte della build. In questo modo, puoi controllare il file di testo nel tuo sistema di controllo del codice sorgente e avere una cronologia delle versioni di come il tuo schema si è evoluto nel tempo. SchemaCrawler è progettato per automatizzare anche questo, dalla riga di comando.