Quali sono alcune strategie per mantenere uno schema di database comune con un team di sviluppatori e nessun DBA?

Question

Sono curioso di sapere come altri hanno affrontato il problema di mantenere e sincronizzare le modifiche del database tra molti (10+) sviluppatori senza un DBA? Ciò che intendo, in sostanza, è che se qualcuno vuole apportare una modifica al database, quali sono alcune strategie per farlo? (Ad esempio, ho creato un modello "Car" e ora voglio applicare il DDL appropriato al database, ecc.)

Siamo principalmente un negozio Python e il nostro ORM è SQLAlchemy. In precedenza, avevamo scritto i nostri modelli in modo tale da creare i modelli utilizzando il nostro ORM, ma abbiamo recentemente piantato in asso perché:

• non potevamo tenere traccia delle modifiche utilizzando l'ORM
• Lo stato del ORM wasn in sincronia con il database (ad esempio, molte differenze relative principalmente agli indici e ai vincoli univoci)
• Non è stato possibile verificare le modifiche del database a meno che lo sviluppatore non abbia documentato la modifica del database via e-mail al team.

La nostra soluzione a questo problema è stato quello di avere fondamentalmente un individuo "gatekeeper" che controlla ogni cambiamento nel database e applica tutte le modifiche al database accettati a un file accepted_db_changes.sql, per cui gli sviluppatori che hanno bisogno di apportare modifiche al database messo la loro richieste in un file proposed_db_changes.sql. Controlliamo questo file e, quando viene aggiornato, applichiamo la modifica al nostro database personale sul nostro computer di sviluppo. Non creiamo indici o vincoli sui modelli, questi vengono applicati esplicitamente sul database.

Vorrei sapere quali sono alcune strategie per mantenere gli schemi di database e se la nostra sembra ragionevole.

Grazie!

Answer 1

La soluzione è piuttosto amministrativo allora tecnico :)

La regola generale è facile, ci dovrebbe essere solo le dipendenze ad albero nel progetto: - Ci deve essere sempre una sola fonte maestro di schema, conservati insieme con il codice sorgente del progetto nel controllo versione - Tutto ciò che è interessato dalla modifica della sorgente master dovrebbe essere automaticamente rigenerato ogni volta che la sorgente master viene aggiornata, nessun intervento manuale è consentito mai, se la generazione automatica non funziona, correggere entrambi sorgente principale o generatore, non aggiornare manualmente il codice sorgente - Tutte le generazioni successive devono essere eseguite dalla stessa persona che ha aggiornato la sorgente principale e tutte le modifiche s compresa la modifica della sorgente principale deve essere considerata una singola transazione (commit di controllo a sorgente singola, singola compilazione/distribuzione per ogni ambiente interessato incluso aggiornamento dei DB)

Essendo applicato, questo fornisce un risultato affidabile al 100%.

Ci sono essenzialmente 3 possibili scelte della sorgente maestro 1) metadati DB, fonti sono generati dopo l'aggiornamento DB da un attrezzo di collegamento al vivo DB 2) codice sorgente, qualche strumento sta generando regime SQL dalle sorgenti, annotato in un modo speciale e quindi SQL viene eseguito sul DB 3) DDL, sia lo schema SQL che il codice sorgente sono generati da alcuni strumenti 4) viene utilizzata un'altra descrizione (ad esempio un file di testo letto da uno speciale script Perl che genera entrambi Schema SQL e il codice sorgente)

1,2,3 sono ugualmente buoni, a condizione che lo strumento di cui avete bisogno esiste e non sia troppo costoso 4 è un approccio universale, bu t dovrebbe essere applicato fin dall'inizio del progetto e ha un sovraccarico di coppia migliaia di righe di codice in una lingua strana per mantenere

Answer 2

Hai provato gli strumenti SQLalchemy Migrate?

Sono specificamente progettati per la migrazione automatica delle modifiche alla progettazione del database.

Answer 3

Quindi ho ragione nel presupporre che stai progettando il tuo db direttamente sul db fisico? Lo facevo molti anni fa ma la qualità del db risultante era piuttosto scarsa. Se si utilizza uno strumento di modellazione (personalmente penso che Sybase pdesigner sia ancora il migliore, ma si guardi attorno) tutti possono apportare modifiche al modello e solo sincronizzare i propri db locali come richiesto (raccoglieranno anche attività di documentazione). Quindi, il post di Bob Bob, il master è il modello pdesigner piuttosto che un db fisico.

Il file accepted_db_changes.sql è un elenco enorme di script di modifica? Non sono sicuro che mi piace l'idea di cambiare il nome del file, ecc Dato che la differenza tra due versioni db è un elenco sequenziale di script alter, come su un modello come:

Ver1 (folder) 
    Change 1-1.sql 
    Change 1-2.sql 
    Change 1-3.sql 
Ver2 (folder) 
    Change 2-1.sql 
    Change 2-2.sql 
    Change 2-3.sql 

Dove ogni cambio (nuovo file) viene esaminato prima di impegnarsi.

Una regola generale dovrebbe essere quella di fare uno sforzo cosciente per automatizzare la maggior parte della distribuzione db nei propri ambienti di sviluppo il più possibile; abbiamo provocatoriamente ottenuto un ROI rispettabile su questo lavoro. Puoi usare strumenti come redgate per generare il tuo ddl (ha una API, non sono sicuro che funzioni con SQLAlchemy). IMO, le modifiche ai DB dovrebbero essere banali, se stai scoprendo che stanno bloccando, guarda cosa puoi automatizzare.

Answer 4

È possibile trovare il libro Refactoring Databases utile in quanto contiene strategie generali per la gestione del database, non solo su come rifattorizzarle.

Il suo sistema si aspetta che ogni sviluppatore disponga della propria copia del database e di un database di test generale utilizzato prima della distribuzione in produzione. La tua situazione è una delle situazioni più semplici descritte nel libro in quanto non hai un numero di applicazioni separate che utilizzano il database (anche se hai bisogno di qualcuno che sappia come descrivere le migrazioni dei database). La cosa più importante è essere in grado di costruire il database dalle informazioni nel controllo del codice sorgente e avere modifiche descritte da piccole migrazioni (si veda la risposta di @ WoLpH) piuttosto che apportare le modifiche al database. Inoltre troverai le cose più facili se hai almeno ORM < -> test del database per verificare che siano ancora sincronizzati.