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

Spesso mi imbatto nel seguente problema.

Lavoro su alcune modifiche a un progetto che richiedono nuove tabelle o colonne nel database. Apporto le modifiche al database e continuo il mio lavoro. Di solito mi ricordo di annotare le modifiche in modo che possano essere replicate sul sistema live. Tuttavia, non ricordo sempre cosa ho cambiato e non ricordo sempre di scriverlo.

Quindi, eseguo una spinta al sistema live e ottengo un grosso errore evidente che non esiste NewColumnX , ugh.

Indipendentemente dal fatto che questa potrebbe non essere la migliore pratica per questa situazione, esiste un sistema di controllo della versione per i database? Non mi interessa la tecnologia specifica del database. Voglio solo sapere se ne esiste uno. Se capita di funzionare con MS SQL Server, allora fantastico.

In Ruby on Rails, c'è un concetto di migrazione : uno script veloce per cambiare il database.

Si genera un file di migrazione, che ha regole per aumentare la versione del database (come l'aggiunta di una colonna) e regole per il downgrade della versione (come la rimozione di una colonna). Ogni migrazione è numerata e una tabella tiene traccia della versione corrente del database.

Per migrare verso l'alto , esegui un comando chiamato "db: migrate" che esamina la tua versione e applica gli script necessari. Puoi migrare verso il basso in modo simile.

Gli stessi script di migrazione sono conservati in un sistema di controllo della versione: ogni volta che si modifica il database, si archivia un nuovo script e qualsiasi sviluppatore può applicarlo per portare il proprio database locale alla versione più recente.

Sono un po 'vecchia scuola, in quanto utilizzo i file sorgente per creare il database. In realtà ci sono 2 file - project-database.sql e project-updates.sql - il primo per lo schema e i dati persistenti e il secondo per le modifiche. Naturalmente, entrambi sono sotto il controllo del codice sorgente.

Quando il database cambia, aggiorno prima lo schema principale in project-database.sql, quindi copio le informazioni rilevanti in project-updates.sql, ad esempio le istruzioni ALTER TABLE. Posso quindi applicare gli aggiornamenti al database di sviluppo, testarli, iterarli finché non vengono eseguiti correttamente. Quindi, archivia i file, prova di nuovo e applica alla produzione.

Inoltre, di solito ho una tabella nel db - Config - come:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

L' db_versionunico viene modificato quando il database viene ricreato e il filedb_revision mi dà un'indicazione di quanto il db è fuori dalla linea di base.

Potevo mantenere gli aggiornamenti in file separati, ma ho scelto di schiacciarli tutti insieme e utilizzare taglia e incolla per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere ":" da $ Revision 1.1 $ per bloccarli.

MyBatis (precedentemente iBatis) ha una migrazione dello schema , uno strumento da utilizzare sulla riga di comando. È scritto in java anche se può essere utilizzato con qualsiasi progetto.

Per ottenere una buona pratica di gestione delle modifiche al database, è necessario identificare alcuni obiettivi chiave. Pertanto, il sistema MyBatis Schema Migration (o MyBatis Migrations in breve) cerca di:

• Lavora con qualsiasi database, nuovo o esistente
• Sfrutta il sistema di controllo del codice sorgente (es.Subversion)
• Consenti a sviluppatori o team simultanei di lavorare in modo indipendente
• Consenti conflitti molto visibili e facilmente gestibili
• Consenti la migrazione in avanti e all'indietro (evolve, devolve rispettivamente)
• Rendi lo stato attuale del database facilmente accessibile e comprensibile
• Consenti le migrazioni nonostante i privilegi di accesso o la burocrazia
• Lavora con qualsiasi metodologia
• Incoraggia pratiche buone e coerenti

Redgate ha un prodotto chiamato SQL Source Control . Si integra con TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce e Git.

Consiglio vivamente SQL delta . Lo uso solo per generare gli script diff quando ho finito di codificare la mia funzione e controllo quegli script nel mio strumento di controllo del codice sorgente (Mercurial :))

Hanno sia un server SQL che una versione Oracle.

Mi chiedo che nessuno abbia menzionato lo strumento open source liquibase che è basato su Java e dovrebbe funzionare per quasi tutti i database che supportano jdbc. Rispetto a rails utilizza xml invece di ruby ​​per eseguire le modifiche allo schema. Sebbene non mi piaccia xml per i linguaggi specifici del dominio, il vantaggio molto interessante di xml è che liquibase sa come ripristinare determinate operazioni come

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Quindi non è necessario che tu gestisca questo da solo

Sono supportate anche istruzioni SQL pure o importazioni di dati.

La maggior parte dei motori di database dovrebbe supportare il dump del database in un file. So che MySQL lo fa, comunque. Questo sarà solo un file di testo, quindi puoi inviarlo a Subversion, o qualunque cosa tu usi. Sarebbe facile anche eseguire un diff sui file.

Se utilizzi SQL Server, sarebbe difficile battere Data Dude (noto anche come Database Edition di Visual Studio). Una volta capito, fare un confronto dello schema tra la versione controllata dal codice sorgente del database e la versione in produzione è un gioco da ragazzi. E con un clic puoi generare il tuo DDL diff.

C'è un video didattico su MSDN che è molto utile.

So di DBMS_METADATA e Toad, ma se qualcuno potesse inventare un Data Dude per Oracle, la vita sarebbe davvero dolce.

Avere le istruzioni iniziali create table nel controller di versione, quindi aggiungere le istruzioni alter table, ma non modificare mai i file, solo più alterare i file idealmente denominati sequenzialmente, o anche come "set di modifiche", in modo da poter trovare tutte le modifiche per una particolare distribuzione.

La parte più difficile che posso vedere è il monitoraggio delle dipendenze, ad esempio, per una particolare tabella di distribuzione potrebbe essere necessario aggiornare la tabella B prima della tabella A.

Per Oracle, utilizzo Toad , che può eseguire il dump di uno schema su un numero di file discreti (ad esempio, un file per tabella). Ho alcuni script che gestiscono questa raccolta in Perforce, ma penso che dovrebbe essere facilmente realizzabile in quasi tutti i sistemi di controllo delle revisioni.

Dai un'occhiata al pacchetto Oracle DBMS_METADATA.

In particolare, risultano particolarmente utili i seguenti metodi:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Una volta che hai familiarità con il loro funzionamento (abbastanza autoesplicativo) puoi scrivere un semplice script per scaricare i risultati di questi metodi in file di testo che possono essere posti sotto il controllo del codice sorgente. In bocca al lupo!

Non sono sicuro che ci sia qualcosa di così semplice per MSSQL.

Scrivo i miei script di rilascio del db parallelamente alla codifica e conservo gli script di rilascio in una sezione specifica del progetto in SS. Se apporto una modifica al codice che richiede una modifica al db, aggiorno contemporaneamente lo script di rilascio. Prima del rilascio, eseguo lo script di rilascio su un db di sviluppo pulito (struttura copiata dalla produzione) e faccio il mio test finale su di esso.

L'ho fatto di tanto in tanto per anni, gestendo (o cercando di gestire) le versioni dello schema. Gli approcci migliori dipendono dagli strumenti che hai. Se riesci a ottenere lo strumento Quest Software "Schema Manager" sarai in buona forma. Oracle ha il suo strumento inferiore, chiamato anche "Schema Manager" (che confonde molto?) Che non consiglio.

Senza uno strumento automatizzato (vedi altri commenti qui su Data Dude), utilizzerai direttamente script e file DDL. Scegli un approccio, documentalo e seguilo rigorosamente. Mi piace avere la possibilità di ricreare il database in qualsiasi momento, quindi preferisco avere un'esportazione DDL completa dell'intero database (se sono il DBA), o dello schema dello sviluppatore (se sono nel prodotto -modalità di sviluppo).

PLSQL Developer, uno strumento di All Arround Automations, ha un plug-in per i repository che funziona bene (ma non eccezionale) con Visual Source Safe.

Dal web:

Il plug-in di controllo della versione fornisce una stretta integrazione tra l'IDE per sviluppatori PL / SQL >> e qualsiasi sistema di controllo della versione che supporti la specifica dell'interfaccia Microsoft SCC. >> Include i più diffusi sistemi di controllo della versione come Microsoft Visual SourceSafe, >> Merant PVCS e MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio ti consente di invertire lo schema del tuo database nello strumento e puoi quindi confrontarlo con i database live.

Esempio: inverti il ​​tuo schema di sviluppo in ER Studio, confrontalo con la produzione ed elencherà tutte le differenze. Può scrivere le modifiche o semplicemente farle passare automaticamente.

Una volta che hai uno schema in ER Studio, puoi salvare lo script di creazione o salvarlo come binario proprietario e salvarlo nel controllo della versione. Se vuoi tornare a una versione precedente dello schema, dai un'occhiata e trasferiscilo sulla tua piattaforma db.

C'è un "framework di migrazione del database" PHP5 chiamato Ruckusing. Non l'ho usato, ma gli esempi mostrano l'idea, se usi il linguaggio per creare il database come e quando necessario, devi solo tenere traccia dei file di origine.

È possibile utilizzare Microsoft SQL Server Data Tools in Visual Studio per generare script per oggetti di database come parte di un progetto SQL Server. È quindi possibile aggiungere gli script al controllo del codice sorgente usando l'integrazione del controllo del codice sorgente incorporata in Visual Studio. Inoltre, i progetti di SQL Server consentono di verificare gli oggetti di database utilizzando un compilatore e di generare script di distribuzione per aggiornare un database esistente o crearne uno nuovo.

Abbiamo utilizzato MS Team System Database Edition con un discreto successo. Si integra con il controllo della versione TFS e Visual Studio più o meno perfettamente e ci consente di gestire facilmente i processi, le visualizzazioni, ecc. Archiviati. La risoluzione dei conflitti può essere un problema, ma la cronologia delle versioni è completa una volta terminata. Successivamente, le migrazioni al QA e alla produzione sono estremamente semplici.

È giusto dire che è un prodotto versione 1.0, tuttavia, e non è privo di alcuni problemi.

Schema Compare per Oracle è uno strumento progettato specificamente per migrare le modifiche dal nostro database Oracle a un altro. Visitare l'URL di seguito per il collegamento per il download, dove sarà possibile utilizzare il software per una prova completamente funzionale.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

In assenza di un VCS per le modifiche alle tabelle, le ho registrate in un wiki. Almeno allora posso vedere quando e perché è stato cambiato. È tutt'altro che perfetto in quanto non tutti lo stanno facendo e abbiamo più versioni del prodotto in uso, ma meglio di niente.

Consiglierei uno dei due approcci. Innanzitutto, investi in PowerDesigner di Sybase. Enterprise Edition. Ti consente di progettare modelli di dati fisici e molto altro ancora. Ma viene fornito con un repository che ti consente di archiviare i tuoi modelli. Ogni nuovo check in può essere una nuova versione, può confrontare qualsiasi versione con qualsiasi altra versione e persino con ciò che è nel database in quel momento. Quindi presenterà un elenco di tutte le differenze e chiederà quale dovrebbe essere migrato ... e poi costruirà lo script per farlo. Non è economico ma è un vero affare al doppio del prezzo e il ROI è di circa 6 mesi.

L'altra idea è attivare il controllo DDL (funziona in Oracle). Questo creerà una tabella con ogni modifica apportata. Se interroghi le modifiche dall'orario in cui hai spostato l'ultima volta le modifiche del database a prod in questo momento, avrai un elenco ordinato di tutto ciò che hai fatto. Alcune clausole where per eliminare i cambiamenti a somma zero come create table foo; seguito da drop table foo; e puoi FACILMENTE costruire uno script mod. Perché mantenere le modifiche in un wiki, è il doppio del lavoro. Lascia che il database li rintracci per te.

Due libri consigliati: "Refactoring Databases" di Ambler e Sadalage e "Agile Database Techniques" di Ambler.

Qualcuno ha menzionato Rails Migrations. Penso che funzionino alla grande, anche al di fuori delle applicazioni Rails. Li ho usati su un'applicazione ASP con SQL Server che stavamo trasferendo a Rails. Controlla gli stessi script di migrazione nel VCS. Ecco un post di Pragmatic Dave Thomas sull'argomento.