Come si effettua la versione dello schema del database? [chiuso]

Come prepari i tuoi delta SQL? salvate manualmente ogni SQL che modifica lo schema in una cartella delta o avete una sorta di processo di diffing automatico?

Sono interessato alle convenzioni per lo schema del database delle versioni insieme al codice sorgente. Forse un hook pre-commit che differenzia lo schema?

Inoltre, quali opzioni per diversi delta esistono oltre a DbDeploy ?

EDIT: vedendo le risposte, vorrei chiarire che ho familiarità con lo schema standard per l'esecuzione di una migrazione del database usando delta. La mia domanda riguarda la creazione dei delta stessi, preferibilmente automaticamente.

Inoltre, il versioning è per PHP e MySQL se fa la differenza. (Nessuna soluzione Ruby per favore).

Vedere

Esiste un sistema di controllo della versione per le modifiche alla struttura del database?

Come posso eseguire la versione del mio database MS SQL in SVN?

e l'articolo di Jeff

Porta il tuo database sotto controllo versione

Sento il tuo dolore e vorrei che ci fosse una risposta migliore. Questo potrebbe essere più vicino a quello che stavi cercando.

Meccanismi per il rilevamento delle modifiche dello schema DB

In generale, penso che non ci sia una soluzione accettata adeguata a questo, e mi metto il mio in quest'area.

Potresti dare un'occhiata a un altro thread simile: come posso eseguire la versione del mio database MS SQL in SVN? .

Se stai ancora cercando opzioni: dai un'occhiata a neXtep designer. Si tratta di un ambiente di sviluppo di database GPL gratuito basato sui concetti di controllo della versione. Nell'ambiente lavori sempre con entità con versione e puoi concentrarti sullo sviluppo del modello di dati. Una volta effettuata una versione, il motore di generazione SQL collegato al sistema di controllo della versione può generare qualsiasi delta necessario tra 2 versioni e offrirà un meccanismo di consegna se necessario.

Tra le altre cose, è possibile sincronizzare e invertire la sincronizzazione del database durante gli sviluppi, creare diagrammi di modelli di dati, eseguire query sul database utilizzando client SQL integrati, ecc.

Dai un'occhiata al wiki per maggiori informazioni: http://www.nextep-softwares.com/wiki

Attualmente supporta Oracle, MySql e PostgreSql ed è in Java, quindi il prodotto funziona su Windows, Linux e Mac.

Mi assicuro che le modifiche allo schema siano sempre additive. Quindi non trascino colonne e tabelle, perché ciò eliminerebbe i dati e non potrà essere ripristinato in seguito. In questo modo è possibile eseguire il rollback del codice che utilizza il database senza perdere dati o funzionalità.

Ho uno script di migrazione che contiene istruzioni che creano tabelle e colonne se non esistono ancora e le riempiono di dati.

Lo script di migrazione viene eseguito ogni volta che il codice di produzione viene aggiornato e dopo nuove installazioni.

Quando desidero rilasciare qualcosa, lo faccio rimuovendoli dallo script di installazione del database e dallo script di migrazione in modo che questi elementi obsoleti dello schema vengano gradualmente eliminati nelle nuove installazioni. Con lo svantaggio che le nuove installazioni non possono eseguire il downgrade a una versione precedente prima dell'installazione.

E ovviamente eseguo DDL tramite questi script e mai direttamente sul database per mantenere le cose sincronizzate.

Non gestisco i delta. Apporto le modifiche a un database master e ho uno strumento che crea uno script di build basato su XML basato sul database master.

Quando arriva il momento di aggiornare un database esistente, ho un programma che utilizza lo script di build basato su XML per creare un nuovo database e le tabelle nude. Quindi copio i dati dal vecchio database usando INSERT INTO x SELECT FROM y e quindi applico tutti gli indici, i vincoli e i trigger.

Nuove tabelle, nuove colonne, colonne eliminate vengono tutte gestite automaticamente e con alcuni piccoli accorgimenti per regolare la routine di copia, posso gestire i nomi delle colonne, le modifiche al tipo di colonna e altri refactoring di base.

Non consiglierei questa soluzione su un database con un'enorme quantità di dati, ma aggiorno regolarmente un database di oltre 1 GB con 400 tabelle.

Non hai menzionato quale RDBMS stai usando, ma se si tratta di MS SQL Server, SQL Compare di Red-Gate è stato indispensabile per noi nel creare delta tra script di creazione di oggetti.

Non sono uno che fa il mio clacson, ma ho sviluppato un'app Web interna per tenere traccia delle modifiche agli schemi del database e creare script di aggiornamento con versione.

Questo strumento si chiama Brasile ed è ora open source con una licenza MIT. Il Brasile è basato su ruby ​​/ ruby ​​su rotaie e supporta l'implementazione delle modifiche su qualsiasi database supportato da Ruby DBI (MySQL, ODBC, Oracle, Postgres, SQLite).

È previsto il supporto per mettere gli script di aggiornamento nel controllo versione.

http://bitbucket.org/idler/mmp - strumento di versioning dello schema per mysql, scritto in PHP

Esportiamo i dati in un formato portatile (usando la nostra toolchain), quindi li importiamo in un nuovo schema. non è necessario delta SQL. Altamente raccomandato.

Uso il database Firebird per gran parte dello sviluppo e per questo utilizzo lo strumento di amministrazione FlameRobin . Ha una bella opzione per registrare tutte le modifiche. Può registrare tutto in un unico file di grandi dimensioni o in un file per modifica del database. Uso questa seconda opzione e quindi memorizzo ogni script nel software di controllo della versione - prima ho usato Subversion, ora uso Git.

Suppongo che tu possa trovare alcuni strumenti MySQL che hanno la stessa funzionalità di registrazione di FlameRobin per Firebird.

In una delle tabelle del database, memorizzo il numero di versione della struttura del database, in modo da poter aggiornare facilmente qualsiasi database. Ho anche scritto un semplice script PHP che esegue uno alla volta quegli script SQL su qualsiasi database di destinazione (percorso del database e nome utente / password sono forniti sulla riga di comando).

C'è anche un'opzione per registrare tutte le istruzioni DML (insert, update delete), e le attivo mentre modifico alcuni dati 'predefiniti' che ogni database contiene.

Ho scritto un bel libro bianco su come faccio tutto questo in dettaglio. Puoi scaricare il documento in formato .pdf insieme agli script demo PHP da qui .

Ho anche sviluppato un set di script PHP in cui gli sviluppatori possono inviare i loro script deltasql a un repository centrale.

In una delle tabelle del database (denominata TBSYNCHRONIZE), memorizzo il numero di versione dell'ultimo script eseguito, in modo da poter aggiornare facilmente qualsiasi database utilizzando l'interfaccia Web o un client sviluppato appositamente per Eclipse.

L'interfaccia Web consente di gestire diversi progetti. Supporta anche "rami" di database.

Puoi testare l'applicazione su http://www.gpu-grid.net/deltasql (se accedi come amministratore con password testdbsync). L'applicazione è open source e può essere scaricata qui: http://sourceforge.net/projects/deltasql

deltasql è utilizzato in modo produttivo in Svizzera e in India ed è popolare in Giappone.

Alcuni mesi fa ho cercato lo strumento per il controllo delle versioni dello schema MySQL. Ho trovato molti strumenti utili, come la migrazione di Doctrine, migrazione RoR, alcuni strumenti scritti in Java e Python.

Ma nessuno di loro era soddisfatto delle mie esigenze.

Le mie esigenze:

1. Nessun requisito, escludi PHP e MySQL
2. Nessun file di configurazione dello schema, come schema.yml in Doctrine
3. In grado di leggere lo schema corrente dalla connessione e creare un nuovo script di migrazione, che rappresenti lo schema identico in altre installazioni dell'applicazione.

Ho iniziato a scrivere il mio strumento di migrazione e oggi ho la versione beta.

Per favore, provalo, se sei interessato a questo argomento. Vi prego di inviarmi richieste e segnalazioni di errori futuri.

Codice sorgente: bitbucket.org/idler/mmp/src Panoramica in inglese: bitbucket.org/idler/mmp/wiki/Home Panoramica in russo: antonoff.info/development/mysql-migration-with-php-project

Uso http://code.google.com/p/oracle-ddl2svn/

Sono interessato anche a questo argomento.

Ci sono alcune discussioni su questo argomento nel wiki di Django .

È interessante notare che sembra che CakePHP abbia il controllo delle versioni dello schema integrato usando solo il cake schema generatecomando.

Per MySQL

Quando atterro su un nuovo DB:

In primo luogo, controllo la struttura:

mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql
mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql
diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt
cat DIFF_FILENAME.txt | less

Grazie agli utenti di StackOverflow ho potuto scrivere questo veloce script per trovare differenze di struttura.

src: https://stackoverflow.com/a/8718572/4457531 & https://stackoverflow.com/a/26328331/4457531

In un secondo passo, controllo i dati, tabella per tabella con mysqldiff. È un po 'arcaico ma un ciclo php basato su information_schemadati rende sicuramente il lavoro

Per il controllo delle versioni, utilizzo allo stesso modo ma formatto uno script di aggiornamento SQL (per l'aggiornamento o il rollback) con risultati diff e utilizzo la convenzione del numero di versione (con diverse modifiche il numero di versione assomiglia a un indirizzo IP) .

initial version : 1.0.0
                  ^ ^ ^
                  | | |
structure change: - | |
datas added: -------- |
datas updated: --------

Sto usando un rigoroso controllo delle versioni dello schema del database (tracciato in una tabella separata). Gli script sono archiviati nel controllo versione, ma tutti verificano la versione corrente dello schema prima di apportare qualsiasi modifica.

Ecco l'implementazione completa per SQL Server (la stessa soluzione potrebbe essere sviluppata per MySQL se necessario): Come mantenere la versione dello schema del database di SQL Server

Dopo lunghe indagini, ho capito che ci sono alcuni strumenti di terze parti o tipi di progetti di Visual Studio che non mi soddisfano, o solo blog sulla teoria ma nessuna implementazione. Quindi ho implementato un sistema funzionante, che viene utilizzato quasi un anno, e spiegato qui:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

a seconda dell'interesse, continuerà a scrivere di più.