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

08-06-2019
|

Domanda

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 sempre ricordo cosa ho cambiato e non sempre mi ricordo di scriverlo.

Quindi, eseguo un push sul sistema live e ottengo un errore grosso ed evidente che non esiste NewColumnX, uff.

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

Soluzione

In Ruby on Rails c'è il concetto di a migrazione -- uno script veloce per modificare il database.

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

A 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 inserisce un nuovo script e qualsiasi sviluppatore può applicarlo per portare il proprio database locale alla versione più recente.

Altri suggerimenti

Sono un po' vecchio stile, 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 innanzitutto 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, testare, ripetere finché non vengono eseguiti correttamente.Quindi, archivia i file, esegui nuovamente il test e applicali 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';

IL db_version viene modificato solo quando il database viene ricreato e il file db_revision mi dà un'indicazione di quanto il db è fuori dalla linea di base.

Avrei potuto mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e di utilizzare taglia e incolla per estrarre le sezioni rilevanti.È necessario fare un po' più di pulizia, ad esempio rimuovere ":" da $Revision 1.1 $ per congelarli.

MyBatis (precedentemente iBatis) ha a migrazione dello schema, strumento da utilizzare sulla riga di comando.È scritto in Java ma può essere utilizzato con qualsiasi progetto.

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

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

Redgate ha un prodotto chiamato Controllo del codice sorgente SQL.Si integra con TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce e Git.

Consiglio vivamente Delta SQL.Lo uso semplicemente 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 una versione SQL Server che 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 ai rail utilizza xml invece di ruby per eseguire le modifiche allo schema.Anche se non mi piace XML per linguaggi specifici del dominio, il vantaggio davvero 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 la cosa da solo

Sono supportate anche le istruzioni SQL pure o le 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 potresti inviarlo a Subversion o qualunque cosa tu usi.Sarebbe facile eseguire anche un diff sui file.

Se utilizzi SQL Server, sarebbe difficile battere Data Dude (noto anche come Database Edition di Visual Studio).Una volta capito come funziona, eseguire 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 diff DDL.

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

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

Disponi delle istruzioni create per la tabella iniziale nel controller di versione, quindi aggiungi le istruzioni alter table, ma non modificare mai i file, solo più alter file denominati idealmente in sequenza o anche come "set di modifiche", in modo da poter trovare tutte le modifiche per una particolare distribuzione.

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

Per Oracle, utilizzo Rospo, che può eseguire il dump di uno schema in 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 praticamente in qualsiasi sistema di controllo di revisione.

Dai un'occhiata al pacchetto Oracle DBMS_METADATA.

In particolare risultano particolarmente utili le seguenti modalità:

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.Buona fortuna!

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

Scrivo i miei script di rilascio 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 del database, aggiorno contemporaneamente lo script di rilascio.Prima del rilascio, eseguo lo script di rilascio su un db di sviluppo pulito (copiato la struttura dalla produzione) ed eseguo i miei test finali su di esso.

Lo faccio di tanto in tanto da anni: gestendo (o tentando di gestire) le versioni dello schema.Gli approcci migliori dipendono dagli strumenti di cui disponi.Se riesci a ottenere lo strumento "Schema Manager" di Quest Software sarai in buona forma.Oracle ha il suo strumento inferiore chiamato anche "Schema Manager" (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 plugin per i repository che funziona bene (ma non benissimo) 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.>>Ciò include i sistemi di controllo della versione più diffusi come Microsoft Visual SourceSafe, >>Merant PVCS e MKS Source Integrity.

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

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

Esempio:Inverti il tuo schema di sviluppo in ER Studio: confrontalo con la produzione ed elencherà tutte le differenze.Può creare script per le modifiche o semplicemente inviarle automaticamente.

Una volta ottenuto uno schema in ER Studio, è possibile salvare lo script di creazione oppure salvarlo come binario proprietario e salvarlo nel controllo della versione.Se mai desideri tornare a una versione precedente dello schema, dai un'occhiata e invialo alla tua piattaforma db.

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

Puoi usare Strumenti dati di Microsoft SQL Server 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 utilizzando l'integrazione del controllo del codice sorgente incorporata in Visual Studio.Inoltre, i progetti SQL Server consentono di verificare gli oggetti del database utilizzando un compilatore e generare script di distribuzione per aggiornare un database esistente o crearne uno nuovo.

Noi abbiamo usato Edizione del database del sistema MS Team con un discreto successo.Si integra più o meno perfettamente con il controllo della versione TFS e Visual Studio e ci consente di gestire facilmente processi, visualizzazioni, ecc. archiviati.La risoluzione dei conflitti può essere una seccatura, ma una volta completata la cronologia delle versioni.Successivamente, le migrazioni al QA e alla produzione sono estremamente semplici.

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

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

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 così posso vedere quando e perché è stato cambiato.È tutt'altro che perfetto poiché non tutti lo fanno e abbiamo più versioni di prodotto in uso, ma meglio di niente.

Consiglierei uno dei due approcci.Innanzitutto, investi in PowerDesigner da Sybase.Edizione aziendale.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 è presente nel tuo database in quel momento.Presenterà quindi un elenco di tutte le differenze e chiederà quale dovrebbe essere migrato... e quindi creerà 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 dal timestamp in cui hai spostato l'ultima volta le modifiche del database su Prod in questo momento, avrai un elenco ordinato di tutto ciò che hai fatto.Alcune clausole where per eliminare modifiche a somma zero come create table foo;seguito da drop table foo;e puoi FACILMENTE creare uno script mod.Perché mantenere le modifiche in una wiki, raddoppia il lavoro.Lascia che il database li tenga traccia per te.

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

Qualcuno ha menzionato le migrazioni di Rails.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 su Rails.Controlla gli script di migrazione stessi nel VCS.Ecco un post del pragmatico Dave Thomas a questo proposito.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow