DISABILITARE ADBLOCK

ADBlock sta bloccando alcuni contenuti del sito

ADBlock errore
risultati trovati: 

DOMANDA

Incontro spesso il 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, faccio una spinta al sistema live e ricevo un grosso, ovvio errore 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 specifica tecnologia del database. Voglio solo sapere se ne esiste uno. Se funziona con MS SQL Server, va benissimo.

SOLUZIONE

In Ruby on Rails c'è il 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 di db.

Per migrare su , 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 verifica un nuovo script e qualsiasi sviluppatore può applicarlo per portare il proprio db locale all'ultima versione.

Se ti va lasciaci una tua opinione

L'articolo ti è stato utile ed è tradotto correttamente?

ALTRI SUGGERIMENTI

Sono un po 'vecchio stile, in quanto utilizzo i file di origine 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, per prima cosa aggiorno 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, iterare fino a quando non viene eseguito correttamente. Quindi, controlla i file, riprova e applica alla produzione.

Inoltre, di solito ho una tabella in 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: 

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

UPDATE Config SET cfg_value='$Revision: 

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

), ( 'db_revision', '$Revision:

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

<*>

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

);

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

<*>

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

WHERE cfg_tag='db_revision';

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

), ( 'db_revision', '$Revision:

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

<*>

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

);

Quindi, aggiungo quanto segue alla sezione di aggiornamento:

<*>

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

Potrei mantenere gli aggiornamenti in file separati, ma ho scelto di unirli tutti insieme e usare cut & amp; paste per estrarre le sezioni pertinenti. È necessario un po 'più di pulizia, cioè rimuovere': 'da $ Revision 1,1 $ per congelarli.

MyBatis (precedentemente iBatis) ha un migrazione schema , strumento da utilizzare nella riga di comando. È scritto in Java anche se può essere utilizzato con qualsiasi progetto.

  

Per raggiungere una buona pratica di gestione delle modifiche al database, dobbiamo identificare alcuni obiettivi chiave.   Pertanto, il sistema di migrazione dello schema MyBatis (o in breve MyBatis Migrations) cerca di:

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

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

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

Hanno entrambi un server SQL e amp; Versione Oracle.

Mi chiedo che nessuno abbia menzionato lo strumento open source liquibase che è basato su Java e dovrebbe funzionare per quasi tutti database che supporta jdbc. Rispetto alle rotaie utilizza xml anziché ruby ??per eseguire le modifiche allo schema. Anche se non mi piace xml per le lingue specifiche 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 gestirlo da soli

Sono supportate anche istruzioni sql pure o importazioni di dati.

La maggior parte dei motori di database dovrebbe supportare il dumping 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 eseguire un diff anche sui file.

Se si utilizza SQL Server, sarebbe difficile battere Data Dude (aka Database Edition di Visual Studio). Una volta capito, fare un confronto dello schema tra la versione del database controllata dalla fonte e la versione in produzione è un gioco da ragazzi. E con un clic puoi generare il tuo DDL diff.

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

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

Fai in modo che le tue iniziali di creazione delle tabelle siano nel controller di versione, quindi aggiungi le istruzioni alter table, ma non modificare mai i file, solo i file alter più idealmente nominati in sequenza, o anche come "set di modifiche", in modo da poter trovare tutte le modifiche per una distribuzione particolare.

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

Per Oracle, utilizzo Toad , che può scaricare uno schema su un numero di file discreti (ad es. 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 Oracle DBMS_METADATA.

In particolare, sono 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 sottoposti al controllo del codice sorgente. Buona fortuna!

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

Scrivo i miei script di rilascio del db in parallelo con la 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 db, aggiorno contemporaneamente lo script di rilascio. Prima del rilascio, eseguo lo script di rilascio su un dev db pulito (struttura copiata dal punto di vista della produzione) e faccio i miei test finali su di esso.

L'ho fatto e spento 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 "Gestore di schemi" (molto confuso?) che non consiglio.

Senza uno strumento automatico (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 di sviluppo (se sono nel prodotto -modalità di sviluppo).

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

  

Dal web:

     
    

Il plug-in Controllo versione fornisce una stretta integrazione tra l'IDE sviluppatore PL / SQL > > e qualsiasi sistema di controllo versione che supporta le specifiche dell'interfaccia Microsoft SCC. > > questo include i sistemi di controllo versione più diffusi 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 confrontare per vivere database.

Esempio: invertire lo schema di sviluppo in ER Studio: confrontarlo con la produzione ed elencherà tutte le differenze. Può scrivere le modifiche o semplicemente inserirle 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 versione. Se vuoi tornare a una versione precedente dello schema, dai un'occhiata e spingilo sulla tua piattaforma db.

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

Puoi utilizzare 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 integrata 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.

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

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

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

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 modificato. È tutt'altro che perfetto poiché non tutti lo fanno e abbiamo in uso più versioni del prodotto, ma meglio di niente.

Consiglierei uno dei due approcci. Innanzitutto, investi in PowerDesigner da Sybase. Edizione Enterprise. 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. Presenterà quindi un elenco di tutte le differenze e chiederà quali dovrebbero essere migrati ... e poi costruisce lo script per farlo. Non è economico ma è un affare al doppio del prezzo e il ROI è di circa 6 mesi.

L'altra idea è di attivare il controllo DDL (funziona in Oracle). Questo creerà una tabella con ogni modifica apportata. Se richiedi le modifiche dal timestamp in cui hai spostato l'ultima volta le modifiche al database in prod in questo momento, avrai un elenco ordinato di tutto ciò che hai fatto. Alcune clausole in cui eliminare le modifiche 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, questo è il doppio del lavoro. Lascia che il database li segua per te.

Raccomandazioni su due libri: " Database di refactoring " di Ambler e Sadalage e "Tecniche di database Agile" di Ambler.

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow