Sì. Dovresti essere in grado di ricostruire qualsiasi parte del tuo sistema dal controllo del codice sorgente incluso il database (e vorrei anche argomentare alcuni dati statici).

Supponendo che non vuoi avere uno strumento per farlo, ti suggerirei di includere quanto segue:

• Script di creazione per le strutture di base della tabella inclusi schemi, utenti, tabelle, chiavi, valori predefiniti e così via.
• Aggiorna gli script (modificando la struttura della tabella o eseguendo la migrazione dei dati da uno schema precedente al nuovo schema)
• Script di creazione per stored procedure, indici, viste, trigger (non devi preoccuparti dell'aggiornamento per questi, basta sovrascrivere quello che c'era con lo script di creazione corretto)
• Script per la creazione dei dati per far funzionare il sistema (un singolo utente, qualsiasi dato statico di picklist, quel genere di cose)

Tutti gli script devono includere le istruzioni di rilascio appropriate e devono essere scritti in modo che possano essere eseguiti come qualsiasi utente (quindi includendo prefissi dello schema / proprietario associati se pertinenti).

Il processo di aggiornamento / tagging / branching dovrebbe essere esattamente come il resto del codice sorgente - non ha molto senso farlo se non è possibile associare una versione del database con una versione dell'applicazione.

Per inciso, quando dici che le persone possono semplicemente aggiornare il server di test, spero che intendi il server di sviluppo. Se gli sviluppatori stanno aggiornando il server di prova al volo, stai guardando un mondo di dolore quando si tratta di elaborare ciò che è necessario rilasciare.

Sì.

what is the best method to keep it and update it there?

Um. Scrivi uno script costruttore di schemi. Controllalo dopo aver apportato le modifiche. Controllalo prima di eseguirlo.

È difficile determinare cosa stai chiedendo.

Scrivi script di migrazione dello schema formale. Controllali dopo il test. Controllali prima di eseguirli.

Che altro c'è?

Ciò che accade è che i cambiamenti dello schema si trasformano in problemi nodali perché lo schema si evolve organicamente attraverso una serie di modifiche non documentate.

Questa evoluzione organica rende più difficile la migrazione degli schemi perché non esiste una fonte "autorevole" per ciò che dovrebbe essere lì. Ci sono due versioni di produzione leggermente diverse, una versione di staging, una versione di QA e otto versioni di sviluppo. Tutto leggermente diverso.

Se esisteva un'unica fonte autorevole, la migrazione dello schema è solo il delta tra l'ultima versione e questa versione.

Sì

Gli script di database (ddl, dml) sono codice. Tutto il codice dovrebbe trovarsi in un sistema di controllo della versione.

Migrazioni

• Utilizza le migrazioni del database

Ti consente di utilizzare gli stessi file db in sviluppo, qa e versioni.

• Rilascio al database con un numero di rilascio

Memorizza il numero di rilascio da qualche parte per il controllo, molti lo memorizzano nel db stesso. Ogni versione sarà composta da migrazioni che porteranno il database alla versione corretta.

Esistono strumenti come liquibase che hanno lo scopo di fornire il controllo del codice sorgente per i database. È difficile mantenere gli script di modifica / aggiornamento nel normale strumento di controllo del codice sorgente come fanno molte aziende e non è sempre possibile ridistribuire il database da zero.

Abbiamo anche provato ad automatizzarlo con gli strumenti di confronto dei database (confronta master e cliente db) e questo ha aiutato, ma non puoi fidarti di questi strumenti al 100%, hai sicuramente bisogno anche di un processo di revisione.

Sì

E furthemore, ti consigliamo di rami .

Uso Git per i rami:

• per lo sviluppo per funzione (come facciamo per lo sviluppo regolare del resto dell'applicazione)

• e uno per il server di produzione anche perché i clienti che utilizzano l'applicazione creano anche contenuti.

In questo modo, ottieni i vantaggi del controllo sorgente e della ramificazione sia per i codici sorgente che per il database (e qualsiasi altro file tu abbia).

Non ho ancora trovato un sistema all-in-one [per PostgreSQL], quindi ho dovuto scrivere correttamente funzioni / script per reindicizzare durante l'unione dei rami (ad es. qualsiasi indice dal ramo di produzione non dovrebbe essere modificato perché i clienti si affidano su di essi mentre gli indici + chiavi esterne dal ramo di sviluppo che si intersecano con i contenuti di produzione dovrebbero essere reindicizzati: non funzionerebbe per tutte le applicazioni, ma copre tutti i casi della nostra applicazione quindi è abbastanza buono).

Ma l'idea generale è che i contenuti del database sono una parte essenziale dell'applicazione e che tutte le risorse dovrebbero essere nel controllo sorgente , quindi sì, dovresti usare anche il controllo del codice sorgente per il database.

Per Java, il nostro team utilizza Flyway , che troviamo davvero facile da usare e potente.

Se lavori in Ruby, Rails ha Migrazioni che sono anche un modo efficace per affrontare questo problema.

Liquibase è già stato menzionato - è una buona soluzione ma l'ho trovato più macchinoso di alternative come Flyway.

Inoltre, il software RedGate offre un prodotto chiamato SQL Source Control che è progettato per SQL Server. Non l'ho usato da solo, ma uno dei miei colleghi dice che è fantastico.

Ecco il problema che ho visto molte volte in cui non esiste controllo di versione o gestione delle modifiche nei database di sviluppo. Il programmatore A apporta una modifica a una tabella, vista o proc. Il programmatore B apporta una modifica alla stessa cosa e sovrascrive ciò che ha fatto il programmatore A. Oppure, DBA ripristina un DB di produzione per lo sviluppo e sovrascrive le modifiche. Ho visto questo genere di cose causare considerevoli dolori così tante volte che non è divertente. E questo è solo sui sistemi di sviluppo. Le cose possono diventare davvero complicate quando lo staging / test e anche i server di produzione vengono coinvolti in questo.

Il controllo della versione del database non deve essere uguale al normale controllo della versione del codice per essere efficace. Tuttavia, alcuni tipi di controllo delle modifiche e backup della cronologia prevengono molti problemi.

Consideralo come "Controllo versione" anziché "Controllo origine". Questo implica che puoi vedere l'intera storia di quel particolare script. Indipendentemente dal fatto che sia possibile ricostruire il database nella sua forma attuale, si tratterà più delle pratiche relative a questi script e a tutti i framework utilizzati per crearli.

Per i nostri progetti PHP / MySQL, abbiamo utilizzato uno (un) piccolo strumento chiamato Ladder . È progettato per facilitare la crescita organica di un database nel tempo. Tutte le migrazioni per un progetto sono archiviate nel controllo revision / source / version e sono tracciate insieme al codice.

Supporta l'aggiunta / modifica / eliminazione di colonne, esecuzione di query, aggiunta / eliminazione di indici, vincoli, ecc., ecc. Troverà lo stato in cui si trova il database e applica eventuali migrazioni mancanti. Consente inoltre di "tornare indietro nel tempo" specificando una migrazione a cui è necessario essere presenti. ( php ladder.php migrate 15 )

Oh, e l'ultima aggiunta è la diffusione del database. Esegui il comando diff-save , aggiungi e rimuovi alcune colonne dal database ed esegui il suo comando diff . Vedrai il codice di migrazione generato automaticamente in base allo stato del database.

DataGrove risolve alcuni dei problemi menzionati qui (da jfrankcarr , ad esempio).

Tiene traccia di tutte le modifiche a un DB e ti consente di salvare una versione dell'intero stato del DB in un repository. Quindi consente di generare più copie virtuali dello stesso DB, quindi ogni sviluppatore o DBA può avere una propria copia separata (ciascuna copia virtuale può essere generata da una versione diversa). Si assicurerà che nessuno sostituisca il codice / le modifiche di qualcun altro. Ciascuna delle copie virtuali viene inoltre rintracciata negli stessi repository in modo che tutti gli stati del DB possano essere facilmente condivisi e ricreati.

Mi piacerebbe anche portare uno strumento di monitoraggio che può anche essere usato come strumento di controllo delle versioni dei dati. Lo strumento di cui sto parlando è MONYog, in realtà è uno strumento di monitoraggio MySQL ma con un piccolo trucco possiamo facilmente usarlo come versioning dei dati.

Ma prima di andare oltre citerò che non è consigliabile mettere tutto il database per il controllo delle versioni. È un vero killer per tracciare il cambiamento di un particolare insieme di dati.

MONyog ha una funzione chiamata CSO (oggetti SQL personalizzati), in grado di monitorare la modifica di un particolare gruppo di dati. L'aggiunta di un CSO è descritta qui . Ora nella sezione della cronologia del monitor di MONyog puoi ottenere le modifiche in un periodo di tempo. La cosa migliore è che fornisce un report visivo nella pagina html. Il rapporto sarà simile a questo