SQL

Question

Sfondo

Il mio gruppo ha Database Server 4 SQL:

• Produzione
• SVS
• prova
• Dev

Lavoro nell'ambiente Dev. Quando arriva il momento di promuovere gli oggetti su cui ho lavorato (tabelle, viste, funzioni, stored proc), faccio una richiesta al mio manager, che promuove Test. Dopo il test, invia una richiesta a un amministratore che promuove l'UAT. Dopo aver testato con successo gli utenti, lo stesso amministratore promuove la produzione.

Il problema

L'intero processo è scomodo per alcuni motivi.

1. Ogni persona deve tracciare manualmente le proprie modifiche. Se aggiorno, aggiungo, rimuovo tutti gli oggetti di cui ho bisogno per rintracciarli in modo che la mia richiesta di promozione contenga tutto ciò che ho fatto. In teoria, se mi manca qualcosa, test o UAT dovrebbero prenderlo, ma questo non è certo ed è uno spreco di tempo del tester, comunque.
2. Un sacco di modifiche apportate sono iterative e eseguite in una GUI, il che significa che non c'è alcuna registrazione di quali modifiche ho apportato, solo il risultato finale (almeno per quanto ne so).
3. Siamo in una fase abbastanza precoce della costruzione di un data mart, quindi la maggior parte delle modifiche apportate, almeno per il conteggio, sono minori: modifica del tipo di dati per una colonna, modifica dei nomi delle tabelle come abbiamo cristallizzare ciò che essi saranno utilizzati per, funzioni e stored procedure, ecc

tweaking La questione

persone hanno fatto questo tipo di lavoro per decenni, quindi immagino ci hanno avuto modo di essere un modo molto migliore per gestire il processo. Quello che mi piacerebbe è se potessi eseguire un diff tra due database per vedere come fosse diversa la struttura, usare quella diff per generare uno script di modifica, usare quello script di cambiamento come richiesta di promozione. È possibile? In caso contrario, ci sono altri modi per organizzare questo processo?

Per la cronaca, siamo un negozio Microsoft al 100%, aggiornando ora tutto a SQL Server 2008, quindi qualsiasi strumento disponibile in quel pacchetto sarebbe equo.

---

Devo chiarire che non sono necessariamente alla ricerca di strumenti di diffusione. Se questo è il modo migliore per sincronizzare i nostri ambienti, allora va bene, ma se c'è un modo migliore, lo sto cercando.

Un esempio di ciò che voglio davvero sono le migrazioni in Ruby on Rails. Morto sintassi semplice, tutte le modifiche sono ben documentate automaticamente e, per impostazione predefinita, determinare quali migrazioni devono essere eseguite è quasi banalmente semplice. Mi piacerebbe se ci fosse qualcosa di simile a questo per SQL Server.

La mia soluzione ideale è 1) facile e 2) difficile da incasinare. Le migrazioni delle rotaie sono entrambe; tutto ciò che ho fatto finora su SQL Server non è né l'uno né l'altro.

Answer 1

Version Control and your Database

La radice di tutte le cose male, sta apportando modifiche nell'interfaccia utente. SSMS è uno strumento DBA, non uno sviluppatore. Gli sviluppatori devono utilizzare gli script per eseguire qualsiasi tipo di modifica al modello/schema del database. Il controllo della versione dei metadati e lo script di aggiornamento da ogni versione N alla versione N + 1 è il modo solo che ha dimostrato di funzionare in modo affidabile. È la soluzione che SQL Server implementa per tenere traccia delle modifiche dei metadati (cambiamenti delle risorse db).

Strumenti di confronto come SQL Compare o vsdbcmd e file .dbschema da progetti di database VS sono solo l'ultimo resort per negozi che non riescono a fare un approccio con versione corretta. Funzionano in scenari semplici, ma li vedo tutti fallire in modo spettacolare in implementazioni serie. Uno solo non si fida uno strumento per fare una modifica alla tabella di + 5 TB se gli strumenti cerca di copia i dati ...

Answer 2

RedGate vende SQL Compare, uno strumento eccellente per generare script di modifica.

Visual Studio ha anche edizioni che supportano il confronto del database. Questo era precedentemente chiamato Database Edition.

Dove lavoro, abbiamo abolito la separazione Dev/Test/UAT/Prod molto tempo fa in favore di uno very quick release cycle. Se mettiamo qualcosa di rotto in produzione, lo sistemeremo rapidamente. I nostri clienti sono certamente più felici, ma nel rischio evitare l'impresa aziendale, può essere una vendita difficile.

Answer 3

Ci sono diversi strumenti disponibili per voi. Uno è di Red-Gate chiamato SQL Compare. Fantastico e altamente raccomandato. SQL Compare ti consente di fare uno schema diverso tra due database e persino di costruire gli script di cambio sql per te.

Nota che hanno lavorato anche a un prodotto di controllo del codice sorgente di SQL Server per un po 'di tempo.

Un altro (se sei un negozio di studio visivo) è lo schema e le funzionalità di confronto dei dati che fanno parte di Visual Studio (non sono sicuro quali versioni).

Answer 4

All'interno della nostra squadra, gestiamo le modifiche del database come questo:

• Noi (ri) generare un sceneggiatura che crea il completa banca dati e controllare in controllo di versione insieme alle altre modifiche. Abbiamo 4 file: tabelle, funzioni e viste definite dall'utente, stored procedure e autorizzazioni. Questo è completamente automatico: è sufficiente un doppio clic per generare lo script.
• Se uno sviluppatore deve apportare modifiche al database, lo fa sul suo db locale.
• Per ogni modifica, creiamo gli script di aggiornamento . Quelli sono facili da creare: lo sviluppatore rigenera lo script db del suo db locale. Tutte le modifiche sono ora facili da identificare grazie al controllo della versione. La maggior parte delle modifiche (nuove tabelle, nuove viste, ecc.) Possono essere semplicemente copiate nello script di aggiornamento, altre modifiche (aggiungendo colonne per esempio) devono essere create manualmente.
• Lo script di aggiornamento è testato sul nostro database di sviluppo comune oppure eseguendo il rollback del db locale sull'ultimo backup, creato prima di iniziare a modificare il database. Se passa, è il momento di impegnare le modifiche.
• Gli script di aggiornamento seguono una convenzione di denominazione in modo che tutti sappiano in quale ordine eseguirli.

Questo funziona abbastanza bene per noi, ma necessita ancora di un coordinamento se diversi sviluppatori modificano pesantemente le stesse tabelle e visualizzazioni. Questo però non accade spesso.

I punti importanti sono:

• struttura del database è solo modificata dagli script, ad eccezione db dello sviluppatore locale. Questo è importante.
• script SQL sono di versione dal controllo del codice sorgente - il db può essere creato come è stato in qualsiasi punto nel passato banca dati
• backup vengono creati regolarmente - almeno prima di apportare modifiche al db
• le modifiche al db possono essere eseguite rapidamente, poiché gli script per tali modifiche vengono creati in modo relativamente semplice.

Tuttavia, se si dispone di molti rami di sviluppo di lunga durata per i propri progetti, questo potrebbe non funzionare correttamente.

Non è assolutamente una soluzione perfetta e devono essere prese alcune precauzioni speciali. Ad esempio, se ci sono aggiornamenti che possono fallire a seconda dei dati presenti in un database, l'aggiornamento dovrebbe essere testato su una copia del database di produzione.

Al contrario delle migrazioni dei binari, non vengono creati script per invertire le modifiche di un aggiornamento. Tuttavia, ciò non è sempre possibile, almeno rispetto ai dati (il contenuto di una colonna rilasciata viene perso anche se si ricrea la colonna).

Answer 5

D'accordo che SQL Compare è uno strumento straordinario.

Tuttavia, non apportiamo alcuna modifica alla struttura del database o agli oggetti che non sono scriptati e salvati nel controllo del codice sorgente come tutti gli altri codici. Quindi sai esattamente cosa appartiene alla versione che stai promuovendo perché hai gli script per quella particolare versione.

È comunque una cattiva idea apportare modifiche strutturali tramite la GUI. Se hai molti dati, è molto più lento che usare alter table almeno in SQL Server. Si desidera utilizzare solo script testati per apportare modifiche ai prodotti.

Answer 6

Un altro strumento "Diff" per i database:

http://www.xsqlsoftware.com/Product/Sql_Data_Compare.aspx

Answer 7

I d'accordo con i commenti fatti da Marapet, in cui ogni cambiamento deve essere copiato.
Il problema che si sta verificando, tuttavia, è la creazione, il test e il monitoraggio di questi script.
Dai un'occhiata al motore di correzione utilizzato in DBSourceTools.
http://dbsourcetools.codeplex.com

E 'stato progettato specificamente per aiutare gli sviluppatori a ottenere database SQL server sotto il controllo del codice sorgente.

Questo strumento consente di baseline il database in un punto specifico e creare una versione denominata (v1).
Quindi, creare un obiettivo di distribuzione e incrementare la versione denominata in v2.
Aggiungere script di patch alla directory Patches per eventuali modifiche allo schema o ai dati.
Infine, controllare il database e tutte le patch nel controllo del codice sorgente, da distribuire con gli sviluppatori.

Ciò che questo ti dà è un processo ripetibile per testare tutte le patch da applicare dalla v1 alla v2.
DBSourceTools dispone inoltre di funzionalità che consentono di creare questi script, ad esempio lo schema di confronto o gli strumenti di dati di script.

Una volta terminato, è sufficiente inviare tutti i file nella directory patch al proprio DBA per eseguire l'aggiornamento da v1 a v2.

Buon divertimento.

Answer 8

1. versione del database Conservare in una tabella delle versioni
2. Tenere scritto il nome del file che è stato applicato con successo
3. Tenere MD5 di ogni script SQL che è stato applicato. Dovrebbe ignorare gli spazi quando si calcola la somma md5. Deve essere efficace.
4. Tenere informazioni su chi applicato uno script Mantenere informazioni su quando è stato applicato uno script
5. database deve essere verificata sulla domanda di start-up
6. nuovo script SQL deve essere applicato automaticamente
7. Se MD5 di uno script che è stato già applicato è stato modificato, l'errore dovrebbe essere generato (in una modalità di produzione)
8. Quando lo script è stato rilasciato, non deve essere modificato. Deve essere immutabile in un ambiente di produzione.
9. script dovrebbe essere scritto in un certo senso, in modo che possa essere applicato a diversi tipi di database (vedi liquibase)
10. Dal momento che la maggior parte delle istruzioni DDL sono auto-commettere sulla maggior parte dei database, è meglio avere una singola istruzione DDL per Script SQL.
11. La dichiarazione DDL sql deve essere eseguita in un modo, quindi può essere eseguita più volte senza errori. Aiuta davvero in una modalità di sviluppo, quando puoi modificare lo script più volte. Ad esempio, crea una nuova tabella, solo se non esiste, o addirittura rilascia una tabella prima di crearne una nuova. Ti aiuterà in una modalità di sviluppo, con uno script che non è stato rilasciato, lo cambi, cancella la somma md5 per questo script, lo ripete nuovamente.
12. Ogni script sql deve essere eseguito nella propria transazione.
13. I trigger/procedure devono essere eliminati e creati dopo ogni aggiornamento db .
14. script SQL è conservato in un sistema di controllo delle versioni come svn
15. nome di uno script contiene data in cui è stata commessa, esistente (JIRA) problema id, piccola descrizione
16. Evitare l'aggiunta di funzionalità di ripristino negli script (liquibase permette di fare quella). Li rende più complicati da scrivere e supportare.Se si utilizza esattamente un istruzione DDL per ogni script e DML dichiarazioni sono esegue all'interno di una transazione , anche in mancanza di uno script non sarà un grosso guaio per risolverlo