Ci dovrebbero essere schemi di database separati per ogni sviluppatore o dovrebbe essercene uno solo che tutti gli sviluppatori condividano?

La risposta giusta è probabilmente "entrambi". Questo si inserisce nella separazione produzione / messa in scena / sviluppo utilizzata in molti cicli di sviluppo.

• I server di sviluppo / test sono disponibili, se necessario, agli sviluppatori in modo che possano progettare nuove funzionalità e eseguire test di regressione con totale libertà e impunità; nulla può rompersi così male che non puoi semplicemente ricominciare da capo e tornare attivo per il prossimo test in pochissimo tempo rispetto a un rollback di istantanee VM.
• I server di gestione temporanea esistono allo scopo di combinare tutte le funzionalità di tutti i diversi sviluppatori e di eseguire test più estesi su modelli reali o ragionevoli di dati reali. Avere un sistema di staging separato significa che è possibile testare la distribuzione delle nuove funzionalità senza rischiare dati reali; È possibile eseguire il test sulla macchina di gestione temporanea fino a quando la distribuzione diventa totalmente di routine.
• I server Production di solito sono completamente off limits per gli sviluppatori. Le conoscenze apprese sui sistemi di stadiazione significa che il personale IT può seguire una procedura pezzo per pezzo. Lo staff IT è spesso molto più bravo a tenere registri di quali modifiche sono state apportate al server di produzione rispetto agli sviluppatori, e questo è A-OK! Al massimo, gli sviluppatori hanno sufficienti credenziali sui server di produzione per guardare i registri, ma anche questo potrebbe essere meglio affidato all'IT.

Ogni sviluppatore dovrebbe avere una propria copia del database per lo sviluppo. Periodo. Qualsiasi altra cosa si frappone e può causare ostacoli nell'ambiente di sviluppo. IMO, non c'è niente di peggio che inseguire un bug per ore causato da una modifica apportata da qualcun altro a dei dati che stai utilizzando nel tuo debug.

Dal momento che questo è più lavoro per gli amministratori di database, è necessario gestire tutte le modifiche dello schema con gli script e automatizzare la distribuzione di tali script. Ci sono tantissimi strumenti per aiutarti (e molti di questi sono gratuiti).

Penso che gli sviluppatori che hanno database separati causino più problemi di quanti ne evitino. Innanzitutto, i nostri database sono grandi, non c'è modo che si adattino alle macchine sviluppatore. Sviluppare contro un piccolo sottoinsieme è sicuramente un modo per ottenere codice che non funzionerà su prod (perché è scaduto) che è uno spreco di tempo e fatica da parte di tutti.

Successivamente, se il mio cambiamento sta andando in conflitto con il cambiamento di qualcun altro, prima lo scopriremo, meglio è. In questo modo nessuno di noi passa molto tempo a dedicarsi a un cambiamento che non può o non può accadere e possiamo vedere che ciò su cui ognuno di noi sta lavorando è realizzato e quindi parla di come integrare le cose il prima possibile. Le persone vedono questo come un segno negativo nel lavorare con un database condiviso (perché è scomodo), per me è uno dei più grandi vantaggi (perché impedisce il lavoro di ripristino a lungo termine).

Disponiamo di un database scratch in cui le persone possono giocare con i concetti prima che siano pronti a metterli nei veri database.

Bene, ci deve essere una copia centrale del database per mantenere lo schema ufficiale.

Per la regressione e il test unitario, dovrebbe essere disponibile un database di esempio contenente dati fittizi ma ragionevoli e un database vuoto, entrambi completamente aggiornati con lo schema più recente del database master. Gli script possono essere utilizzati per creare queste copie. Il database di esempio è utile per il test, mentre il database vuoto è utile per le nuove installazioni.

Idealmente, i test unitari dovrebbero essere progettati utilizzando le transazioni del database, in modo che i test che aggiungono, modificano o cancellino i record possano ripristinare la transazione per riportare il database allo stato originale.

Molti programmi forniscono un meccanismo per modificare lo schema del database al volo, che sarebbe un requisito per la distribuzione di un aggiornamento del software a qualsiasi cliente che abbia già dati nel proprio database.

Solo un'aggiunta: deve esserci un db centrale. Se uno degli sviluppatori manca qualcosa, è probabile che lo stesso problema (all'interno dello stesso db) venga catturato da un altro sviluppatore. E sì, è necessario assicurarsi che le transazioni DB siano ACID-ized.

Direi di fare quello che vogliono gli sviluppatori. Ogni applicazione è diversa. Alcuni potrebbero chiamarne uno, alcuni potrebbero chiamare l'altro, altri potrebbero chiamare entrambi.

Quindi ... se il programmatore vuole il proprio database, lascia che ne impostino uno (assumendo che lo spazio / le risorse siano disponibili, ovviamente). Se preferiscono utilizzare un database di sviluppo condiviso per qualsiasi motivo, lascia che lo facciano.

Fondamentalmente, limitare gli sviluppatori all'uno o all'altro non aiuta il processo di sviluppo.

La risposta è che le copie del database locale sono buone e dovrebbero essere fatte.

Penso che la vera domanda alla base di questo, però, sia "qual è il processo per gestire le modifiche al database"

Le cose principali da considerare sono:

In che modo gli sviluppatori locali "cambiano". In che modo le modifiche db locali vengono sospinte. In che modo le modifiche centrali al db vengono inviate / disattivate agli sviluppatori.

Ruby in Rails, ad esempio, consente agli sviluppatori di eseguire migrazioni di database utilizzando il codice ruby, quindi la migrazione viene spinto alla staging, test e produzione ed eseguito lì ('centralmente') e inviato ad altri sviluppatori (che lo fanno) per fare lo stesso.

Alla fine della giornata, ciò che è fondamentale per qualsiasi sistema è la comunicazione, sia esso un processo standardizzato o solo e-mail sui cambiamenti.