php - Meccanismi per il rilevamento delle modifiche dello schema DB



mysql database (14)

Quali sono i metodi migliori per tracciare e / o automatizzare le modifiche allo schema del DB? Il nostro team utilizza Subversion per il controllo della versione e siamo stati in grado di automatizzare alcune delle nostre attività in questo modo (invio di build a un server di gestione temporanea, distribuzione di codice testato su un server di produzione) ma stiamo ancora eseguendo manualmente gli aggiornamenti del database. Vorrei trovare o creare una soluzione che ci consenta di lavorare in modo efficiente su server con ambienti diversi continuando a utilizzare Subversion come backend attraverso il quale gli aggiornamenti di codice e DB vengono inviati ai vari server.

Molti pacchetti software popolari includono script di aggiornamento automatico che rilevano la versione del DB e applicano le modifiche necessarie. È questo il modo migliore per farlo anche su larga scala (tra più progetti e talvolta più ambienti e lingue)? In tal caso, esiste un codice esistente che semplifica il processo o è meglio implementare la nostra soluzione? Qualcuno ha implementato qualcosa di simile prima e l'ha integrato negli hook post-commit di Subversion, o è una cattiva idea?

Mentre sarebbe preferibile una soluzione che supporti più piattaforme, dobbiamo sicuramente supportare lo stack Linux / Apache / MySQL / PHP poiché la maggior parte del nostro lavoro è su quella piattaforma.


Answer #1

È un po 'a bassa tecnologia e potrebbe esserci una soluzione migliore là fuori, ma potresti semplicemente archiviare il tuo schema in uno script SQL che può essere eseguito per creare il database. Penso che tu possa eseguire un comando per generare questo script, ma sfortunatamente non conosco il comando.

Quindi, impegna lo script nel controllo del codice sorgente insieme al codice che funziona su di esso. Quando è necessario modificare lo schema insieme al codice, è possibile effettuare il check-in dello script insieme al codice che richiede lo schema modificato. Quindi, le differenze sullo script indicano differenze nelle modifiche allo schema.

Con questo script, è possibile integrarlo con DBUnit o qualche tipo di script di compilazione, quindi sembra che si adatti ai processi già automatizzati.


Answer #2

Consiglierei di usare Ant (multipiattaforma) per il lato "scripting" (dal momento che può praticamente parlare con qualsiasi db là fuori via jdbc) e Subversion per il repository di origine. Ant ti consentirà di "eseguire il backup" del tuo db in file locali, prima di apportare modifiche. 1. eseguire il backup dello schema db esistente su file tramite Ant 2. controllo versione nel repository Subversion tramite Ant 3. inviare nuove istruzioni sql a db tramite Ant


Answer #3

Esiste uno strumento mysql-diff riga mysql-diff comando che confronta gli schemi del database, in cui lo schema può essere un database attivo o uno script SQL sul disco. È utile per la maggior parte delle attività di migrazione dello schema.


Answer #4

Ho usato la seguente struttura di progetto del database in Visual Studio per diversi progetti e ha funzionato abbastanza bene:

Banca dati

Cambia script

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Crea script

sprocs

funzioni

Visualizzazioni

Il nostro sistema di generazione quindi aggiorna il database da una versione alla successiva eseguendo gli script nel seguente ordine:

1.PreDeploy.sql

2.SchemaChanges.sql

Contenuto della cartella Crea script

2.DataChanges.sql

3.Permissions.sql

Ogni sviluppatore controlla le proprie modifiche per un determinato bug / funzionalità aggiungendo il proprio codice alla fine di ogni file. Una volta che una versione principale è completa e ramificata nel controllo del codice sorgente, i contenuti dei file .sql nella cartella Change Scripts vengono eliminati.


Answer #5

Il problema qui sta davvero rendendo facile per gli sviluppatori scrivere le proprie modifiche locali nel controllo del codice sorgente da condividere con il team. Ho affrontato questo problema per molti anni ed è stato ispirato dalla funzionalità dei professionisti di Visual Studio per Database. Se desideri uno strumento open source con le stesse funzionalità, prova questo: http://dbsourcetools.codeplex.com/ Buon divertimento, Nathan.



Answer #7

Mi piace il modo in cui Yii gestisce le migrazioni del database. Una migrazione è fondamentalmente uno script PHP che implementa CDbMigration . CDbMigration definisce un metodo up che contiene la logica di migrazione. È anche possibile implementare un metodo down per supportare l'inversione della migrazione. In alternativa, è possibile utilizzare safeUp o safeDown per assicurarsi che la migrazione venga eseguita nel contesto di una transazione.

Lo strumento da riga di comando di yiic contiene il supporto per creare ed eseguire migrazioni. Le migrazioni possono essere applicate o invertite, una alla volta o in un batch. La creazione di una migrazione comporta il codice di una classe PHP che implementa CDbMigration , denominata in modo univoco in base a un timestamp e un nome di migrazione specificato dall'utente. Tutte le migrazioni che sono state precedentemente applicate al database sono archiviate in una tabella di migrazione.

Per ulteriori informazioni, consultare l'articolo sulla migrazione del database dal manuale.


Answer #8

Nel mondo di Rails, esiste il concetto di migrazioni, script in cui vengono apportate modifiche al database in Ruby piuttosto che un sapore SQL specifico del database. Il codice di migrazione di Ruby finisce per essere convertito nel DDL specifico del database corrente; questo rende molto semplice il passaggio da una piattaforma di database all'altra.

Per ogni modifica apportata al database, scrivi una nuova migrazione. Le migrazioni in genere hanno due metodi: un metodo "up" in cui vengono applicate le modifiche e un metodo "down" in cui le modifiche vengono annullate. Un singolo comando aggiorna il database e può anche essere utilizzato per portare il database a una versione specifica dello schema. In Rails, le migrazioni vengono mantenute nella loro directory nella directory del progetto e vengono controllate nel controllo della versione proprio come qualsiasi altro codice di progetto.

Questa guida Oracle alle migrazioni di Rails copre abbastanza bene le migrazioni.

Gli sviluppatori che utilizzano altre lingue hanno esaminato le migrazioni e hanno implementato le proprie versioni specifiche della lingua. Conosco Ruckusing , un sistema di migrazioni PHP modellato sulle migrazioni di Rails; potrebbe essere quello che stai cercando.



Answer #10

Scarica lo schema in un file e aggiungilo al controllo del codice sorgente. Quindi un semplice diff ti mostrerà cosa è cambiato.


Answer #11

Se stai ancora cercando soluzioni: stiamo proponendo uno strumento chiamato neXtep designer. È un ambiente di sviluppo di database con il quale è possibile mettere l'intero database sotto controllo di versione. Lavori su un repository controllato in versione in cui è possibile tenere traccia di ogni modifica.

Quando è necessario rilasciare un aggiornamento, è possibile eseguire il commit dei componenti e il prodotto genererà automaticamente lo script di aggiornamento SQL dalla versione precedente. Ovviamente, puoi generare questo SQL da qualsiasi 2 versioni.

Quindi hai molte opzioni: puoi prendere quegli script e inserirli nel tuo SVN con il tuo codice app in modo che vengano distribuiti dal tuo meccanismo esistente. Un'altra opzione è quella di utilizzare il meccanismo di consegna di neXtep: gli script vengono esportati in qualcosa chiamato "pacchetto di consegna" (script SQL + descrittore XML) e un installatore può capire questo pacchetto e distribuirlo su un server di destinazione garantendo coerenza strcuturale, dipendenza controllare, registrare la versione installata, ecc.

Il prodotto è GPL e si basa su Eclipse, quindi funziona su Linux, Mac e Windows. Attualmente supporta anche Oracle, Mysql e Postgresql (il supporto DB2 è in arrivo). Dai un'occhiata al wiki dove troverai informazioni più dettagliate: http://www.nextep-softwares.com/wiki


Answer #12

Se stai usando C #, dai un'occhiata a Subsonic, uno strumento ORM molto utile, ma genera anche script sql per ricreare il tuo schema e \ o i tuoi dati. Questi script possono quindi essere messi nel controllo del codice sorgente.

http://subsonicproject.com/


Answer #13

Usiamo qualcosa di simile a bcwoord per mantenere sincronizzati i nostri schemi di database su 5 diverse installazioni (produzione, gestione temporanea e alcune installazioni di sviluppo) e sottoposti a backup nel controllo della versione, e funziona abbastanza bene. Elaborerò un po ':

Per sincronizzare la struttura del database, abbiamo un singolo script, update.php e un numero di file numerati 1.sql, 2.sql, 3.sql, ecc. Lo script utilizza una tabella aggiuntiva per memorizzare il numero di versione corrente del Banca dati. I file N.sql sono creati a mano, per passare dalla versione (N-1) alla versione N del database.

Possono essere utilizzati per aggiungere tabelle, aggiungere colonne, migrare i dati da un vecchio a un nuovo formato di colonna, quindi rilasciare la colonna, inserire righe di dati "master" come tipi di utenti, ecc. Fondamentalmente, può fare qualsiasi cosa e con dati adeguati script di migrazione che non perderai mai dati.

Lo script di aggiornamento funziona in questo modo:

  • Connettiti al database.
  • Fai un backup del database corrente (perché le cose andranno male) [mysqldump].
  • Creare una tabella di contabilità (chiamata _meta) se non esiste.
  • Leggi la VERSIONE corrente dalla tabella _meta. Supponi 0 se non trovato.
  • Per tutti i file .sql con un numero maggiore di VERSION, eseguili in ordine
  • Se uno dei file ha generato un errore: ripristinare il backup
  • Altrimenti, aggiorna la versione nella tabella di contabilità al file .sql più alto eseguito.

Tutto passa al controllo del codice sorgente e ogni installazione ha uno script da aggiornare all'ultima versione con una singola esecuzione dello script (chiamando update.php con la password del database corretta ecc.). SVN aggiorna gli ambienti di gestione temporanea e di produzione tramite uno script che chiama automaticamente lo script di aggiornamento del database, quindi un aggiornamento del codice viene fornito con gli aggiornamenti del database necessari.

Possiamo anche usare lo stesso script per ricreare l'intero database da zero; semplicemente rilasciamo e ricreamo il database, quindi eseguiamo lo script che ripopolerà completamente il database. Possiamo anche usare lo script per popolare un database vuoto per i test automatizzati.

Ci sono volute solo poche ore per configurare questo sistema, è concettualmente semplice e tutti ottengono lo schema di numerazione delle versioni, ed è stato prezioso avere la capacità di andare avanti ed evolvere il design del database, senza dover comunicare o eseguire manualmente le modifiche su tutti i database.

Fai attenzione quando incolli le query da phpMyAdmin! Quelle query generate di solito includono il nome del database, che sicuramente non si desidera poiché interromperà gli script! Qualcosa come CREATE TABLE mydb . newtable (...) fallirà se il database sul sistema non si chiama mydb. Abbiamo creato un hook SVN pre-commento che non consentirà i file .sql contenenti la stringa mydb , che è un segno sicuro che qualcuno copia / incolla da phpMyAdmin senza un controllo adeguato.


Answer #14

Usiamo una soluzione molto semplice ma efficace.

Per le nuove installazioni, abbiamo un file metadata.sql nel repository che contiene tutto lo schema DB, quindi nel processo di compilazione utilizziamo questo file per generare il database.

Per gli aggiornamenti, aggiungiamo gli aggiornamenti nel software hardcoded. Lo teniamo hardcoded perché non ci piace risolvere i problemi prima che sia davvero un problema, e questo genere di cose non si è rivelato essere un problema finora.

Quindi nel nostro software abbiamo qualcosa del genere:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Questo codice verificherà se il database è nella versione 1 (che è memorizzato in una tabella creata automaticamente), se è obsoleto, quindi il comando viene eseguito.

Per aggiornare metadata.sql nel repository, eseguiamo questi aggiornamenti localmente e quindi estraiamo i metadati del database completo.

L'unica cosa che succede ogni tanto è dimenticare di eseguire il commit di metadata.sql, ma questo non è un grosso problema perché è facile testare il processo di compilazione e anche l'unica cosa che potrebbe succedere è fare una nuova installazione con un database obsoleto e aggiornato al primo utilizzo.

Inoltre non supportiamo i downgrade, ma è in base alla progettazione, se qualcosa si interrompe su un aggiornamento, abbiamo ripristinato la versione precedente e riparato l'aggiornamento prima di riprovare.





migration