Versioning Mysql Data (Not Just Schema)

Question

Nel mio ufficio si è parlato della creazione di un pacchetto con controllo della versione di dati mysql (non schemi/migrazioni).

Fondamentalmente il processo funzionerebbe in questo modo. Tieni presente che il client usa ancora il back-end normalmente, l'immagine quindi lo usa come un backend wordpress. Il client effettuerebbe l'accesso selezionando un "ramo" assegnandogli un nome, diciamo "nuovi utenti", questo clonerebbe un database completamente nuovo che consente all'utente di lavorare su quel "ramo" senza effettuare il live. Una volta che il client ha terminato di apportare modifiche ai dati, si unirebbero il ramo dati al "master" (live).

Sotto la cappa, quando si uniscono, si esportano i dati dei rami in tempo reale e "nuovi utenti" in un file sql, si esegue un svn diff e si uniscono le modifiche.

La situazione creatasi che allettati l'idea era, se abbiamo clienti che hanno bisogno di fare un po 'di modifiche al sito c'è, ma non voglio mettere i dati in tempo reale e, mentre essi apportino non desiderano effettuare altri cambiamenti colleghi del sito o. Fondamentalmente replicato ciò che gli sviluppatori fanno quando lavorano in repository come Git.

Inoltre, se il client lavora su un sito di sviluppo/demo, il lavoro che desiderano pubblicare.

Volevo aprire la discussione per capire se questa è anche una buona idea? Quali problemi possiamo incontrare? È una buona pratica di programmazione quando si lavora con i dati? Esiste già qualcosa del genere?

Answer 1

Il database (in particolare i relativi dati) viene raramente memorizzato in un sistema di controllo versione perché non è adatto per i database grandi grandi.

Nel tuo caso, se non avete troppo molti dati, che potrebbe funzionare, soprattutto dal momento che un mysqldump can produce a delimited text format (che ha la possibilità di diff rispetto alla versione precedente)

io consiglierei comunque un repo git separata e uno strumento dedicato per gestire sia lo schema che i cambiamenti dei dati. Ad esempio, LiquidBase può fornire "controllo del codice sorgente per il tuo database".
Hai anche un database specializzato dedicato: off-scale.

Se si dovesse procedere manualmente, allora si hanno delle buone pratiche riassunte in "Recipes for Continuous Database Integration".

Come mentioned here, anche per lo schema:

ho imparato nel modo più duro che l'applicazione di modifiche dello schema del database non può essere fatto in modo affidabile senza un piano globale step-by-step e, allo stesso modo, l'ordine delle dipendenze relazionali sono importante.
La semplice memorizzazione dello schema "corrente" o "fine" non è sufficiente. Esistono molte modifiche che non possono essere applicate in modo retroattivo A->C senza conoscere A->B->C e alcune modifiche B potrebbero coinvolgere la logica di migrazione o le correzioni.

Answer 2

è la vostra esigenze nel modo più semplice seguente:

• Stesso codice di back-end;
• Utilizzare i dati anagrafici in diretta;
• Utenti finali (o gruppo) per lavorare su dati isolati;
• Nessuna migrazione, gli utenti finali possono solo modificare i dati (DML) e non possono modificare lo schema (DDL);

Se questi sono i requisiti, è possibile utilizzare più database. Prendere in considerazione i seguenti database in un server MySQL:

• masterdb
• branch_demo
• branch_brian
• branch_sandbox
• ...

Questi database condividono lo stesso identico schema, e solo i dati sono diversi. In ogni ramo, abbiamo un tavolo speciale (cioè dbinfo), per tenere traccia del ramo principale (probabilmente masterdb), creare datetime, e altri dettagli, come l'accesso a livello, ecc

• id
• branchname
• parent_branch
• created_on
• lastmod_on

È possibile consentire agli utenti finali di lavorare su rami separati, semplicemente consentendo loro di s eleggere un particolare database nell'interfaccia utente, in cui masterdb è selezionato come predefinito e viene utilizzato in LIVE.

• Creazione di un nuovo ramo, sarebbe semplice come la clonazione di un database;
• L'unione di un ramo più nuovo in master può essere gestita utilizzando l'istruzione REPLACE in MySQL;

Se si desidera tenere traccia delle modifiche nei dati, è possibile creare una tabella speciale per registrare le attività.