Condivisione di un database mentre lavoriamo su copie locali?

Question

Condivisione di un database mentre lavoriamo su copie locali?

#1 da (4 voti)

2

Un amico e io stiamo lavorando su una webapp. Stiamo usando git così ognuno di noi ha una copia locale dell'app. Ma il problema è il database. Vogliamo essere in grado di vedere gli ultimi cambiamenti fatti dall'altra persona. Da quello che ho capito, abbiamo due opzioni:

ospita il database su un server
Aggiungi il file .sql a ogni commit che facciamo.

Per la prima opzione, potremmo esporre il nostro sistema ad alcuni rischi (di cui sono spaventato). Per la seconda opzione, aggiungiamo lavoro non necessario alle nostre attività quotidiane (importando il file .sql e quindi creando il file .sql).

Sono nuovo di questa roba - quindi qualsiasi suggerimento è benvenuto!

git database mysql collaboration

posta Utkarsh Sinha 09.10.2012 - 13:37

fonte

1 risposta

Leggi altre domande sui tag git database mysql collaboration

Gestione efficace delle variabili nella programmazione non orientata agli oggetti Quale motivo di progettazione separa i convertitori di trasformazione

score 4 · Answer 1

Qui ci sono due problemi distinti:

Gestione dello schema
Dati di prova

Di gran lunga il problema più grande e più impegnativo è la gestione dello schema: è necessario avere la certezza che ogni istanza del database (che è la stessa "versione") abbia lo stesso schema.

Ci sono molti e diversi approcci a questo (le migrazioni sono incorporate in Ruby on Rails per esempio) ma fondamentalmente si tratta di due cose:

Avere un meccanismo per identificare la versione dello schema nel database
Organizzazione delle modifiche dello schema in modo che possano essere applicate in modo sequenziale (e coerente)

Il meccanismo più semplice (e quello che funziona bene per me) consiste nell'avere una tabella del numero della versione dello schema (ad es. id, data applicata, riepilogo delle modifiche, autore).

In termini di organizzazione delle modifiche dello schema, utilizzo il codice, un metodo per versione dello schema, che consente alle chiamate DDL di modificare lo schema. È relativamente semplice, è efficace e funziona per me. Il vantaggio è che è ripetibile (e può essere incluso nell'automazione), il lato negativo è che è un po 'più lavoro da fare per creare gli script di modifica. Posso quindi definire anche intervalli di versioni dello schema accettabili per una revisione dell'applicazione e rifiutare di eseguire (o eseguire aggiornamenti dello schema o altrimenti adottare i passaggi appropriati) se non corrispondono.

In termini di dati di test ... Non ho buone risposte, potresti volere che uno script popolasse il database con dati di esempio adeguati, detto script dovrà evolversi e crescere. In alternativa puoi controllare la versione di una copia di riferimento che aggiorni di volta in volta.

Fondamentalmente, non dovresti dipendere da modifiche dati arbitrarie fatte in un'altra istanza per essere in grado di sviluppare la tua applicazione (non sto assumendo che tu lo sia, basta fare l'osservazione!) . Se sono necessarie le modifiche ai dati, è probabile che debbano far parte di un aggiornamento della versione dello schema.