In che modo seguire correttamente la modifica della struttura del database da SVN?

Question

Il problema principale è il controllo delle versioni della struttura del database.

Le utilità standard mysqldump e pg_dump non producono file molto adatti per il controllo delle versioni.

I comandi di dump producono i file di dump con valori di autoincremento, voci TOC e così via. Dato che questi oggetti sono soggetti a continue modifiche, produce sempre enormi file di differenze.

PostgreSQL Diff

-- 
--- TOC entry 2630 (class 0 OID 0) 
+-- TOC entry 2549 (class 0 OID 0) 
-- Dependencies: 6 
-- Name: SCHEMA adm; Type: COMMENT; Schema: -; Owner: admin 
@@ -61,5 +61,5 @@ 

MySQL Diff

--- Dump completed on 2010-07-20 14:33:44 
+-- Dump completed on 2010-08-11 8:59:39 
Index: /db.sql 
=================================================================== 
--- /db.sql (revision 1274) 
+++ /db.sql (revision 1317) 
@@ -36,5 +36,5 @@ 
    `message` text, 
    PRIMARY KEY (`id`) 
-) ENGINE=MyISAM AUTO_INCREMENT=21122 DEFAULT CHARSET=utf8; 
+) ENGINE=MyISAM AUTO_INCREMENT=23730 DEFAULT CHARSET=utf8; 

Eventuali suggerimenti/link/Utility del modo migliore di controllo di versione sono apprezzati!

Grazie.

Answer 1

Date un'occhiata a LiquiBase (http://www.liquibase.org/)

Si tratta di uno strumento progettato per consentire agli sviluppatori di commettere modifiche al database di SVN, e poi applicarle in modo sicuro e automaticamente al database.

Le modifiche possono essere decodificate confrontando due database o codificati manualmente dallo sviluppatore e confermati.

Garantisce inoltre che le modifiche al database vengano applicate nell'ordine corretto e applicate solo una volta a un determinato database.

Answer 2

Semplicemente versione degli script utilizzati per creare il database da zero. Gli sviluppatori modificano gli script nei file di testo e non nel database. Gli sviluppatori non hanno accesso ai server SQL di produzione e il team DBA utilizza strumenti specificamente progettati per confrontare gli schemi di database (nel nostro caso, SQLCompare di Red-Gate) al fine di realizzare build di produzione. Creeranno un nuovo database vuoto dagli script e utilizzeranno lo strumento di confronto per rilevare le modifiche. Alcune modifiche possono essere applicate automaticamente e alcune devono essere modificate manualmente.

Non è un sistema perfetto, ma ha funzionato abbastanza bene per noi finora.

Answer 3

Non vorrei usare MySQL discariche perché sono per lo più utilizzati per il backup dei dati, e di solito non uso il controllo di versione per gestire i backup dei dati. Invece, vorrei solo controllare lo script di installazione o il file SQL utilizzato per impostare la struttura iniziale del database.

Per i progetti di piccole dimensioni, di solito ho solo un file chiamato install.sql che contiene tutte le mie istruzioni CREATE e schema.txt che descrive lo schema. Per i progetti più grandi, potresti voler usare qualcosa come dbForge, che consente il versioning dello schema del database nell'edizione professionale, anche se è un po 'costoso se è tutto ciò per cui lo stai usando.

Dai un'occhiata a this article su Coding Horror (in particolare il primo collegamento in quel post) per ulteriori informazioni.

Answer 4

Depesz recentemente ha scritto un post sul blog "HOW TO MANAGE CHANGES TO YOUR DATABASE?"

direi:

• Se semplicemente memorizzare lo schema di ogni oggetto in SVN, è ancora necessario per distribuire le modifiche con dipendenze di ordinazione e dati modifiche, quindi tutto ciò che ti compra davvero sta categorizzando la tua storia di modifiche agli oggetti coinvolti.
• Scrivere gli script per eseguire tutte le modifiche, inclusi gli script per annullare le modifiche.
• Utilizzare apgdiff per produrre differenze di schema del database (PostgreSQL).

Answer 5

È possibile utilizzare gratuitamente Another PostgreSQL Diff Tool per i database PostgreSQL per il confronto dello schema di sviluppo e dello schema di produzione. Semplicemente aggiorna il tuo database di sviluppo nel modo che ritieni più comodo. Quando si desidera aggiornare il database di produzione allo stato del database di sviluppo, si esegue il dump degli schemi di database di sviluppo e degli schemi del database di produzione e si consente a apgdiff di confrontarli. Produrrà output che contiene istruzioni DDL necessarie per trasformare il database di produzione nello stato del database di sviluppo.

Infatti, spetta a te distribuire apgdiff nel tuo ciclo di sviluppo, tutto ciò che fa è creare output con istruzioni DDL per "spostare" il tuo database di produzione allo stesso stato del database di sviluppo.

Sul sito web è possibile trovare informazioni su come funziona, come utilizzarlo, quali istruzioni sono supportate ecc. C'è anche un articolo sull'upgrade dello schema PostgreSQL sul mio blog su www.fordfrog.name (mi è stato permesso di includere solo un collegamento quindi non potrebbe rendere questo link di indirizzo troppo).