Come si inserisce un grande database esistente (schema) sotto il controllo del codice sorgente?

Question

Il mio DBA ha appena perso alcuni lavori di sviluppo che ha fatto sul nostro database di sviluppo. Povero amico. Quindi, naturalmente, il nostro manager gli ha chiesto, durante la nostra riunione sullo stato, come ciò potesse accadere e come avremmo potuto evitare che ciò accadesse in futuro. "Il controllo del codice potrebbe alleviare il problema" ho suggerito ... La risposta del dba; "No, eseguiamo semplicemente il backup del server più spesso". Ora vorrei aiutare il mio DBA a capire quale sia il controllo del codice sorgente e come si adatti allo schema e allo sviluppo del database su quello schema.

In precedenza ho cercato di spiegargli che non c'è niente di speciale nel codice sorgente dietro le tabelle e le stored procedure e dovrebbe essere in un sistema di controllo del codice sorgente (TFS in questo caso). Ma lui non ha morso. Ora, mentre questo misap è nella memoria recente, vorrei prendere un'altra pugnalata a questo.

Quindi la mia domanda è, sai di qualche buon consiglio che potrei trasmettere al mio DBA e forse anche un paio di risorse che spiegano come si andrebbe a migrare uno schema DB per essere sotto il controllo del codice sorgente e trovare il posto giusto nei processi di compilazione e implementazione?

Un paio di fatti riguardanti l'ambiente:

• controllo del codice sorgente su un TFS 2008 Server.
• Il database è un server MS SQL 2008 con> 300 tabelle e> 300 altri oggetti (sprocs, trigger, funzioni ecc.).

Chiarimento: Abbiamo usato DB fantasma e altre soluzioni di gestione dei cambiamenti su altri progetti con altri amministratori di database, in passato. Abbiamo persino la licenza per l'edizione VS DB! Il problema sta nel convincere il DBA a pensare a questo modo di sviluppare il database. Lui è davvero vecchia scuola (ad esempio la migrazione delle modifiche manualmente dall'ambiente all'ambiente), e sfortunatamente è l'unico che sa qualcosa su questo particolare DB.

Answer 1

Vedi how to version control sql server databases e Do you source control your databases, tra molti altri. Oppure usa lo searchpage. Fondamentalmente, il tuo approccio sembra corretto. Buona fortuna per persuadere il DBA ...

Answer 2

non si può davvero mettere un grande database sotto il controllo del codice sorgente, quindi il tuo DBA è giusto.

quello che puoi fare praticamente è mettere il tuo schema sotto il controllo del codice sorgente, e forse alcune tabelle di "configurazione" piuttosto piccole.

Answer 3

Se si utilizza Visual Studio Team System, si consiglia di avere una pugnalata alla loro edizione di database (penso che in questi giorni viene fornito con la Developer Edition se si è un abbonato MSDN). Ciò che questo ti permetterà di fare è di codificare tutti gli schemi, i proc memorizzati, le viste, i trigger, ecc. E il controllo dei sorgenti questi. Questo dovrebbe anche rendere il dba più comodo poiché lavorerà con una versione "Database" dello strumento piuttosto che con la versione "Developer" (la denominazione può andare molto bene con le persone). Quando apporti le modifiche da Visual Studio, puoi gestire le modifiche degli script mentre lavori e il sorgente li controlla.

Answer 4

Se la società ha una licenza MSDN, è possibile utilizzare l'edizione del database di Visual Studio. C'è un video tutorial su di esso here.

Non ho il potere di acquisto, quindi non so quali sono i guasti. Ma ha la capacità di controllare tutte le parti di uno schema DB e include la creazione di script di modifica e l'auto-distribuzione direttamente da VS, se lo si desidera (non lo consiglierei).

In generale, tuttavia, è piuttosto solido come opzione di controllo del codice sorgente del database.

Answer 5

Un modo per procurarsi database di controllo è quello di memorizzare i dati e sul database separatamente

1. si può avere il tutte le tabelle, le procedure e gli script di funzione come file SQL e aggiungerli al controllo del codice sorgente.

2. Esportare i dati del database come istruzioni di inserimento in file SQL, ciascuno con una dimensione fissa. Si tratta di un processo ingombrante poiché implicherebbe un sacco di file che devono essere monitorati e controllati.

3. Non sono sicuro che VSS/SVN sia in grado di leggere e conservare la cronologia delle modifiche ai file di dump creati dalle opzioni di backup del database.

Answer 6

Non è chiaro dalla domanda se si desidera proteggere i dati nel Db o gli schemi nel Db. In quest'ultimo caso, è possibile identificare tutti gli schemi importanti ed eseguire un cron job che estrae le definizioni dello schema dal Db e li inserisce automaticamente in un sistema di controllo del codice sorgente (forse anche tramite trigger sugli schemi ??).

Ma questo equivale ancora a supportare il sistema più spesso. Per quello che prevedi avrai bisogno del controllo del codice sorgente integrato con gli strumenti Db e non conosco nessun prodotto che lo faccia.

(e mi vengono i brividi a pensare a VSS integrato in studio di gestione di SQL: - (()

Answer 7

controllo

Fonte per i database può essere molto controversa E 'diverso da usare controllo del codice sorgente per qualcosa che produce un binario perché è possibile. bloccare la sorgente: un processo memorizzato è una riga in una tabella e non c'è una sola tabella da leggere per ottenere una definizione di tabella

Inoltre, la versione alla versione è principalmente un insieme di istruzioni ALTER. e li aggiungo al controllo del codice sorgente, il che rende più difficile l'utilizzo in casi come questo.

Per me, questo è più un errore procedurale.

Perché il cambiamento non è stato eseguito da uno script? Dimentica dove vive la sceneggiatura, ma perché non ci sono script riproducibili e riproducibili? Forse collegato al numero di tracciamento delle modifiche? Se il database viene ripristinato (caricato da prod), in che modo la modifica sarà stata riapplicata per preparare la produzione. E altre domande.

Credo nel controllo del codice sorgente e lo usiamo: ma ha dei limiti per il lavoro del database.

Answer 8

Per prima cosa ci si avvicina in modo errato. Se il dba non morde sul Controllo Sorgente e sta commettendo errori che influenzano il sistema, la persona che devi persuadere è il suo capo.

Se aiuta, anche io vengo dalla vecchia scuola e adoro avere i nostri oggetti di database nel controllo del codice sorgente. Che bello essere in grado di ripristinare una tabella senza dover ripristinare l'intero backup del database in una posizione diversa e quindi spostare la tabella. Quanto più veloce e semplice. Che bello essere in grado di confrontare due diverse versioni e vedere cosa è cambiato. Che bello distribuire un cambiamento e sapere esattamente quali cambiamenti del database (diciamo, ad esempio, solo dodici dei 23 possibili) andare con la parte che si sta distribuendo e non con qualche altro progetto incompiuto.Che bello sapere esattamente quali script sono stati coinvolti in un particolare cambiamento che hai dovuto eseguire. Che bello che nessuno stia apportando modifiche in tempo reale alla produzione poiché ora richiediamo che tutte le modifiche alla produzione siano da script di controllo del codice sorgente. Ci sono così tanti errori e problemi di cui preoccuparsi.

Sì, è stato un cambiamento nel modo in cui abbiamo fatto affari, ma lo abbiamo fatto attraverso un cambiamento di politica da alto, quindi tre non erano argomenti e il db ha passato un paio di volte e ha ripristinato qualsiasi oggetto diverso dal controllo del codice sorgente versione di controllo del codice sorgente, quindi ora nessuno penserà nemmeno a fare un cambio di database senza che sia nel controllo del codice sorgente.

Answer 9

La mia risposta a questo stesso problema era di esportare tutti gli oggetti DB in un modulo di testo (più di 136.000 di essi) e quindi creare i progetti SourceSafe per conservarli. Qualsiasi oggetto nuovo o modificato nel DB ora passa alla struttura SourceSafe, mentre invariato rimane solo.

Answer 10

Come product manager per SQL Compare ho parlato con molti DBA "tradizionali" che sono a disagio con gli strumenti di terze parti principalmente perché hanno un sistema che funziona per loro e, a volte, il cambiamento può essere difficile. Ci sono molte situazioni in cui sono convinto che trarrebbero beneficio dai nostri strumenti se solo gli dessero una possibilità. Frustrante.

Una cosa che potresti prendere in considerazione è lo strumento imminente di Red Gate, SQL Source Control. Questo è progettato per costruire il controllo del codice sorgente in SSMS, in altre parole non richiede che i DBA lascino la zona di comfort del proprio ambiente di gestione. La cattiva notizia è che lo strumento non è ancora stato rilasciato. La buona notizia è che abbiamo un programma di accesso anticipato. Si prega di visitare il seguente link per saperne di più sullo strumento:

http://www.red-gate.com/Products/SQL_Source_Control/index.htm