Usi il controllo del codice sorgente per gli elementi del tuo database? [chiuso]

Sento che il mio negozio ha un buco perché non abbiamo un solido processo in atto per il controllo delle versioni delle modifiche dello schema del database. Facciamo molti backup, quindi siamo più o meno coperti, ma è una cattiva pratica fare affidamento sull'ultima linea di difesa in questo modo.

Sorprendentemente, questo sembra essere un filo conduttore. Molti negozi con cui ho parlato ignorano questo problema perché i loro database non cambiano spesso e sostanzialmente cercano solo di essere meticolosi.

Tuttavia, so come va questa storia. È solo questione di tempo prima che le cose si allineino e qualcosa vada perduto.

Ci sono delle migliori pratiche per questo? Quali sono alcune strategie che hanno funzionato per te?

Devi leggere Ottieni il tuo database sotto il controllo della versione . Controlla la serie di post di K. Scott Allen.

Quando si tratta di controllo della versione, il database è spesso un cittadino di seconda o addirittura di terza classe. Da quello che ho visto, i team che non avrebbero mai pensato di scrivere codice senza controllo della versione in un milione di anni - e giustamente - possono in qualche modo essere completamente ignari della necessità di controllo della versione nei database critici su cui si basano le loro applicazioni. Non so come definirti un ingegnere del software e mantenere una faccia seria quando il tuo database non ha esattamente lo stesso rigoroso livello di controllo del codice sorgente del resto del codice. Non lasciare che questo accada a te. Porta il tuo database sotto il controllo della versione.

I database stessi? No

Gli script che li creano, inclusi inserimenti di dati statici, procedure memorizzate e simili; ovviamente. Sono file di testo, sono inclusi nel progetto e vengono archiviati come tutti gli altri.

Naturalmente in un mondo ideale il tuo strumento di gestione del database farebbe questo; ma devi solo essere disciplinato al riguardo.

Adoro le migrazioni di Rails ActiveRecord. Estrae lo script DML to ruby ​​che può quindi essere facilmente versione nel repository di origine.

Tuttavia, con un po 'di lavoro, potresti fare la stessa cosa. Qualsiasi modifica DDL (ALTER TABLE, ecc.) Può essere memorizzata in file di testo. Mantenere un sistema di numerazione (o un timbro data) per i nomi dei file e applicarli in sequenza.

Rails ha anche una tabella 'version' nel DB che tiene traccia dell'ultima migrazione applicata. Puoi fare lo stesso facilmente.

Dai un'occhiata a LiquiBase per la gestione delle modifiche al database tramite il controllo del codice sorgente.

Non devi mai semplicemente accedere e iniziare a immettere i comandi "ALTER TABLE" per modificare un database di produzione. Il progetto in cui mi trovo ha un database su ogni sito del cliente, quindi ogni modifica al database viene effettuata in due posizioni, un file di dump che viene utilizzato per creare un nuovo database su un nuovo sito del cliente e un file di aggiornamento che viene eseguito su ogni aggiornamento che verifica il numero della versione del database corrente rispetto al numero più alto nel file e aggiorna il database in posizione. Ad esempio, l'ultimo paio di aggiornamenti:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Sono sicuro che esiste un modo migliore per farlo, ma finora ha funzionato per me.

Sì. Il codice è codice. La mia regola pratica è che devo essere in grado di compilare e distribuire l'applicazione da zero , senza guardare una macchina di sviluppo o produzione.

La migliore pratica che ho visto è la creazione di uno script di build per eliminare e ricostruire il database su un server di gestione temporanea. Ad ogni iterazione è stata assegnata una cartella per le modifiche al database, tutte le modifiche sono state scritte con "Drop ... Create". In questo modo è possibile eseguire il rollback a una versione precedente in qualsiasi momento puntando la cartella build a cui si desidera versione.

Credo che ciò sia stato fatto con NaNt / CruiseControl.

SÌ, penso che sia importante eseguire la versione del database. Non i dati, ma lo schema per certi.

In Ruby On Rails, questo è gestito dal framework con "migrazioni". Ogni volta che si modifica il db, si crea uno script che applica le modifiche e lo controlla nel controllo del codice sorgente.

Al mio negozio è piaciuta così tanto l'idea che abbiamo aggiunto la funzionalità alla nostra build basata su Java usando script di shell e Ant. Abbiamo integrato il processo nella nostra routine di distribuzione. Sarebbe abbastanza facile scrivere script per fare la stessa cosa in altri framework che non supportano il controllo delle versioni del DB immediatamente.

I nuovi progetti di database in Visual Studio forniscono controllo del codice sorgente e script di modifica.

Hanno un bel strumento che confronta i database e può generare uno script che converte lo schema di uno nell'altro o aggiorna i dati in uno per adattarsi all'altro.

Lo schema db viene "distrutto" per creare molti, molti piccoli file .sql, uno per comando DDL che descrive il DB.

+ tom

Ulteriori informazioni 30/11/2008

L'ho usato come sviluppatore per l'anno scorso e mi piace molto. Rende facile confrontare il mio lavoro di sviluppo con la produzione e generare uno script da utilizzare per la versione. Non so se mancano le funzionalità di cui i DBA hanno bisogno per i progetti "di tipo aziendale".

Poiché lo schema viene "distrutto" in file sql, il controllo del codice sorgente funziona correttamente.

Un problema è che devi avere una mentalità diversa quando usi un progetto db. Lo strumento ha un "progetto db" in VS, che è solo sql, oltre a un database locale generato automaticamente che ha lo schema e alcuni altri dati di amministrazione - ma nessuno dei dati dell'applicazione, oltre al db di sviluppo locale che usi per lavoro di sviluppo dati app. Raramente sei a conoscenza del db generato automaticamente, ma devi sapere che è lì in modo da poterlo lasciare da solo :). Questo db speciale è chiaramente riconoscibile perché ha un Guid nel suo nome,

Il progetto VS DB fa un buon lavoro di integrazione delle modifiche di db che altri membri del team hanno apportato al proprio progetto locale / db associato. ma devi fare un passo in più per confrontare lo schema del progetto con il tuo schema di sviluppo locale e applicare le mod. Ha senso, ma all'inizio sembra imbarazzante.

I progetti DB sono uno strumento molto potente. Non solo generano script ma possono applicarli immediatamente. Assicurati di non distruggere il tuo db di produzione con esso. ;)

Mi piacciono molto i progetti VS DB e mi aspetto di utilizzare questo strumento per tutti i miei progetti di database in futuro.

+ tom

Richiedere ai team di sviluppo di utilizzare un sistema di gestione del controllo del codice sorgente del database SQL non è il proiettile magico che eviterà che si verifichino problemi. Di per sé, il controllo del codice sorgente del database introduce un sovraccarico aggiuntivo in quanto gli sviluppatori sono tenuti a salvare le modifiche apportate a un oggetto in uno script SQL separato, aprire il client del sistema di controllo del codice sorgente, controllare il file di script SQL utilizzando il client e quindi applicare le modifiche al database live.

Posso suggerire di utilizzare il componente aggiuntivo SSMS chiamato ApexSQL Source Control . Consente agli sviluppatori di mappare facilmente gli oggetti di database con il sistema di controllo del codice sorgente tramite la procedura guidata direttamente da SSMS. Il componente aggiuntivo include il supporto per TFS, Git, Subversion e altri sistemi SC. Include anche il supporto per il controllo sorgente dei dati statici.

Dopo aver scaricato e installato ApexSQL Source Control, fare semplicemente clic con il pulsante destro del mouse sul database che si desidera controllare la versione e accedere al sottomenu ApexSQL Source Control in SSMS. Fare clic sull'opzione Collega database al controllo del codice sorgente, selezionare il sistema di controllo del codice sorgente e il modello di sviluppo. Successivamente, dovrai fornire le informazioni di accesso e la stringa del repository per il sistema di controllo del codice sorgente che hai scelto.

Puoi leggere questo articolo per ulteriori informazioni: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Faccio salvando gli script di creazione / aggiornamento e uno script che genera sampledata.

Sì, lo facciamo mantenendo il nostro SQL come parte della nostra build: manteniamo DROP.sql, CREATE.sql, USERS.sql, VALUES.sql e la versione li controlliamo, così possiamo tornare a qualsiasi versione taggata.

Abbiamo anche compiti formica che possono ricreare il db ogni volta che è necessario.

Inoltre, SQL viene quindi etichettato insieme al codice sorgente che lo accompagna.

Lo schema di maggior successo che abbia mai usato su un progetto ha combinato backup e file SQL differenziali. Fondamentalmente dovremmo fare un backup del nostro db dopo ogni versione e fare un dump SQL in modo da poter creare uno schema vuoto da zero, se necessario. Quindi, ogni volta che è necessario apportare una modifica al DB, è necessario aggiungere uno scrip alter alla directory sql sotto il controllo della versione. Vorremmo sempre aggiungere un numero di sequenza o una data al nome del file in modo che la prima modifica sia simile a 01_add_created_on_column.sql e lo script successivo sarebbe 02_added_customers_index. La nostra macchina CI controllerebbe questi ed eseguirli in sequenza su una nuova copia del db che era stato ripristinato dal backup.

Avevamo anche alcuni script che gli sviluppatori potevano usare per reinizializzare il loro db locale alla versione corrente con un singolo comando.

Controlliamo il codice sorgente di tutti gli oggetti creati dabase. E solo per mantenere gli sviluppatori onesti (poiché è possibile creare oggetti senza che siano nel controllo del codice sorgente), il nostro dbas cerca periodicamente qualsiasi cosa non sia nel controllo del codice sorgente e se trovano qualcosa, lo rilasciano senza chiedere se è ok.

Uso SchemaBank per controllare la versione di tutte le modifiche allo schema del mio database:

• dal primo giorno, ho importato il mio dump dello schema db in esso
• ho iniziato a cambiare il mio schema di progettazione utilizzando un browser Web (perché sono basati su SaaS / cloud)
• quando voglio aggiornare il mio server db, da esso creo lo script change (SQL) e lo applico al db. In Schemabank, mi obbligano a impegnare il mio lavoro come versione prima che io possa generare uno script di aggiornamento. Mi piace questo tipo di pratica in modo da poter sempre risalire quando ne ho bisogno.

La regola del nostro team è MAI toccare direttamente il server db senza memorizzare prima il lavoro di progettazione. Ma succede, qualcuno potrebbe essere tentato di infrangere la regola, per motivi di convenienza. Vorremmo importare di nuovo il dump dello schema in schemabank e lasciarlo fare il diff e colpire qualcuno in caso di discrepanza. Sebbene potessimo generare gli script alter da esso per sincronizzare il nostro progetto di db e schema, lo odiamo e basta.

A proposito, ci permettono anche di creare rami all'interno dell'albero di controllo della versione in modo che io possa mantenerne uno per la messa in scena e uno per la produzione. E uno per la sandbox di codifica.

Uno strumento di progettazione di schemi basato sul Web piuttosto pulito con controllo di versione e gestione delle modifiche.

Ho tutto il necessario per ricreare il mio DB dal bare metal, meno i dati stessi. Sono sicuro che ci sono molti modi per farlo, ma tutti i miei script e simili sono archiviati in sovversione e possiamo ricostruire la struttura del DB e simili estraendo tutto ciò dalla sovversione ed eseguendo un programma di installazione.

Generalmente creo uno script SQL per ogni modifica apportata e un altro per ripristinare tali modifiche e mantenere tali script sotto il controllo della versione.

Quindi abbiamo un modo per creare un nuovo database aggiornato su richiesta e possiamo facilmente spostarci tra le revisioni. Ogni volta che eseguiamo una versione, raggruppiamo gli script insieme (richiede un po 'di lavoro manuale, ma raramente in realtà è difficile ), quindi abbiamo anche una serie di script che possono essere convertiti tra le versioni.

Sì, prima di dirlo, questo è molto simile alle cose che fanno Rails e altri, ma sembra funzionare abbastanza bene, quindi non ho problemi ad ammettere che ho sollevato spudoratamente l'idea :)

Uso gli script SQL CREATE esportati da MySQL Workbech, quindi utilizzando la loro funzionalità "Esporta SQL ALTER" finisco con una serie di script di creazione (numerati ovviamente) e gli script di modifica che possono applicare le modifiche tra di loro.

3.- Esporta script SQL ALTER Normalmente ora dovresti scrivere le istruzioni ALTER TABLE a mano, riflettendo le modifiche apportate al modello. Ma puoi essere intelligente e lasciare che Workbench faccia il duro lavoro per te. Basta selezionare File -> Esporta -> Forward Engineer SQL ALTER Script ... dal menu principale.

Questo ti chiederà di specificare il file CREATE SQL con il quale confrontare il modello corrente.

Selezionare lo script SQL CREATE dal passaggio 1. Lo strumento genererà quindi lo script ALTER TABLE per l'utente e sarà possibile eseguire questo script sul database per aggiornarlo.

Puoi farlo usando MySQL Query Browser o il client mysql.Voila! Il tuo modello e database sono stati sincronizzati!

Fonte: MySQL Workbench Community Edition: Guida alla sincronizzazione degli schemi

Tutti questi script ovviamente sono all'interno sotto il controllo della versione.

Si Sempre. Dovresti essere in grado di ricreare la struttura del database di produzione con un utile set di dati di esempio ogni volta che è necessario. In caso contrario, nel tempo vengono dimenticate piccole modifiche per mantenere le cose in esecuzione, quindi un giorno vieni morso, alla grande. È un'assicurazione che potresti non pensare di aver bisogno ma il giorno in cui lo fai vale il prezzo 10 volte!

Ci sono state molte discussioni sul modello di database stesso, ma conserviamo anche i dati richiesti nei file .SQL.

Ad esempio, per essere utile l'applicazione potrebbe aver bisogno di questo nell'installazione:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Avremmo un file chiamato currency.sqlsotto sovversione. Come passaggio manuale nel processo di compilazione, confrontiamo il currency.sql precedente con quello più recente e scriviamo uno script di aggiornamento.

Noi versione e sorgente controlliamo tutto ciò che circonda i nostri database:

• DDL (crea e modifica)
• DML (dati di riferimento, codici, ecc.)
• Modifiche al modello di dati (utilizzando ERwin o ER / Studio)
• Modifiche alla configurazione del database (autorizzazioni, oggetti di sicurezza, modifiche alla configurazione generale)

Facciamo tutto questo con lavori automatizzati utilizzando Change Manager e alcuni script personalizzati. Abbiamo Change Manager che controlla queste modifiche e avvisa quando sono state fatte.

Credo che ogni DB dovrebbe essere sotto il controllo del codice sorgente e gli sviluppatori dovrebbero avere un modo semplice per creare il loro database locale da zero. Ispirato da Visual Studio per professionisti del database, ho creato uno strumento open source che esegue lo script di database MS SQL e fornisce e un modo semplice per distribuirli nel motore DB locale. Prova http://dbsourcetools.codeplex.com/ . Divertiti, - Nathan.

Se il tuo database è SQL Server, potremmo avere solo la soluzione che stai cercando. SQL Source Control 1.0 è stato ora rilasciato.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Questo si integra in SSMS e fornisce la colla tra gli oggetti del database e il VCS. Lo "scripting out" avviene in modo trasparente (utilizza il motore SQL Compare sotto il cofano), il che dovrebbe rendere così semplice l'uso che gli sviluppatori non saranno scoraggiati dall'adottare il processo.

Una soluzione alternativa di Visual Studio è ReadyRoll , implementata come sottotipo del progetto di database SSDT. Questo adotta un approccio guidato dalle migrazioni, che è più adatto ai requisiti di automazione dei team DevOps.

Controllo lo schema del database tramite la creazione di script di tutti gli oggetti (definizioni di tabella, indici, stored procedure, ecc.). Ma, per quanto riguarda i dati stessi, è sufficiente fare affidamento su backup regolari. Ciò garantisce che tutte le modifiche strutturali vengano acquisite con un'adeguata cronologia delle revisioni, ma non grava sul database ogni volta che cambiano i dati.

Nella nostra attività utilizziamo gli script di modifica del database. Quando viene eseguito uno script, il suo nome viene archiviato nel database e non verrà eseguito nuovamente, a meno che tale riga non venga rimossa. Gli script sono denominati in base a data, ora e ramo del codice, quindi è possibile l'esecuzione controllata.

Molti test vengono eseguiti prima che gli script vengano eseguiti nell'ambiente live, quindi le "oopsie" si verificano solo, in generale, su database di sviluppo.

Stiamo trasferendo tutti i database nel controllo del codice sorgente. Stiamo usando sqlcompare per eseguire lo script del database (una funzione di edizione professionale, sfortunatamente) e mettere quel risultato in SVN.

Il successo della tua implementazione dipenderà molto dalla cultura e dalle pratiche della tua organizzazione. Le persone qui credono nella creazione di un database per applicazione. Esiste un insieme comune di database che vengono utilizzati dalla maggior parte delle applicazioni e che causano molte dipendenze tra database (alcune sono circolari). Mettere gli schemi di database nel controllo del codice sorgente è stato notoriamente difficile a causa delle dipendenze interdatabase che hanno i nostri sistemi.

In bocca al lupo a te, prima lo provi e prima avrai risolto i tuoi problemi.

Ho usato lo strumento dbdeploy da ThoughtWorks all'indirizzo http://dbdeploy.com/ . Incoraggia l'uso di script di migrazione. Ad ogni versione, abbiamo consolidato gli script delle modifiche in un unico file per facilitare la comprensione e consentire ai DBA di "benedire" le modifiche.

Questo è sempre stato un grande fastidio anche per me - sembra che sia semplicemente troppo facile apportare una rapida modifica al database di sviluppo, salvarlo (dimenticando di salvare uno script di modifica) e poi sei bloccato. Potresti annullare ciò che hai appena fatto e rifarlo per creare lo script di modifica, o scriverlo da zero se vuoi, ovviamente, anche se è molto tempo impiegato a scrivere script.

Uno strumento che ho usato in passato che mi ha aiutato in questo è SQL Delta. Ti mostrerà le differenze tra due database (SQL server / Oracle credo) e genererà tutti gli script di modifica necessari per migrare A-> B. Un'altra cosa interessante che fa è mostrare tutte le differenze tra il contenuto del database tra il DB di produzione (o test) e il DB di sviluppo. Poiché sempre più app memorizzano la configurazione e affermano che è fondamentale per la loro esecuzione nelle tabelle del database, può essere una vera seccatura avere script di modifica che rimuovono, aggiungono e alterano le righe appropriate. Delta SQL mostra le righe nel database proprio come apparirebbero in uno strumento Diff: modificate, aggiunte, eliminate.

Uno strumento eccellente. Ecco il link: http://www.sqldelta.com/

RedGate è eccezionale, generiamo nuove istantanee quando vengono apportate modifiche al database (un piccolo file binario) e conserviamo quel file nei progetti come risorsa. Ogni volta che dobbiamo aggiornare il database, utilizziamo il toolkit di RedGate per aggiornare il database, oltre a essere in grado di creare nuovi database da quelli vuoti.

RedGate crea anche snapshot di dati, anche se non ho lavorato personalmente con loro, sono altrettanto robusti.

Cordiali saluti Questo è stato anche sollevato alcuni giorni fa da Dana ... Stored procedure / schema DB nel controllo del codice sorgente