Best practice per la modifica dello schema di SQL Server 2008

Question

Sto cercando informazioni riguardanti il ??seguente:

Quali sono le migliori pratiche per l'aggiornamento dello schema del mio dev DB per la mia produzione DB, o anche più succintamente fare DB modifiche allo schema in generale.

Il database di produzione è il back-end per due siti web ASP.NET distinti.

Il nostro processo di modifica dello schema è abbastanza robusto con ogni "migrazione" in realtà essere un file con estensione cs contenente le modifiche dello schema. Ci sarà quindi utilizzare ADO.NET per applicare le modifiche allo schema contro il db.

La mia domanda è più circa la connettività del database.

Devo smettere i due siti web che accedono al db. Suppongo che dovrei. Devo mettere il DB in modalità singolo utente. Sembra come dovrei, ma non sono del tutto sicuro su questo.

Che cosa potevo mancare? Quali sono le cose che ti hanno morso la mano prima riguardante DB modifiche dello schema.

Answer 1

Se gli aggiornamenti cambiano le cose come i nomi delle colonne, i parametri di stored procedure, ecc quindi sempre prendere le app offline prima di fare un aggiornamento dello schema.

Se gli aggiornamenti sono solo per le cose che non influiscono sulla normale elaborazione dei dati allora potrebbe essere in grado di farlo "a caldo". Questa categoria è quando si sta aggiungendo cose come indici, tabelle, ecc.

Se qualcuno sta usando l'applicazione, mentre un aggiornamento dello schema è l'elaborazione si potrebbe benissimo trovare in una situazione in cui è compromessa la coerenza dei dati.

Se questo aggiornamento richiede un corrispondente aggiornamento per i file dell'applicazione web poi prendere il sito (s) offline prima di eseguire l'aggiornamento. Tu non sai chi potrebbe essere la visualizzazione di una pagina e in procinto di fare clic su conferma solo per ottenere un errore ...

In genere la manutenzione di questo tipo viene effettuato durante le ore di punta. Si vuole informare gli utenti prima del tempo da quando il sito sarà verso il basso e per quanto tempo.

Inoltre, utilizziamo strumenti come SQL di Redgate confronta con gli script di nostri aggiornamenti db. Questo è praticata su un server di gestione temporanea che era stato rinfrescato da dati di produzione prima della spinta reale al fine di garantire che non ci sono sorprese e può essere fatto molto rapidamente.

Per quanto riguarda la modalità singolo utente, si utilizzano in genere questo per limitare l'accesso a un database a una singola istanza Management Studio. Non è qualcosa che normalmente facciamo come parte delle nostre implementazioni.

Answer 2

Non ho considerato le cs / ado.net percorso di modifiche dello schema di chiusura. Quello che facciamo è creare 'delta' file sql - SQL per apportare le modifiche. Questi sono eseguite rispetto a uno schema di nota di revisione per apportare le modifiche, e in esecuzione il .SQL è parte di una distribuzione.

come meglio possiamo, anche noi provare a fare questi sicuri di eseguire più volte controllando schema per specifici cose come l'esistenza di una colonna, indice, ecc In questo modo si potrebbe essere eseguito 'accidentalmente' più volte.

Quando abbiamo distribuire abbiamo determinate ore del giorno / settimana, avvisare gli utenti / clienti, arresto siti web, ecc Con le implementazioni 'pratica' in corso quasi ogni giorno in dev e messa in scena server gli ultimi giorni prima di un rilascio, fiducia distribuzione finale è alta.

Mantenere le modifiche dello schema in SQL sembrano più il 'master' schema SQL che modifify e sono quindi più facile tenere traccia dei. Meno di eseguire il debug troppo!

Sono inoltre gestite in TFS insieme al resto del codice.

Answer 3

Situazione ideale, ma non sempre realizzabile: Fate le modifiche dello schema che sono compatibili con V versione del tuo sito web. È quindi rilascia V per i server web. Una volta che tutti i server web sono fino a V , è quindi possibile eseguire eventuali pulizie (che popolano i valori mancanti, ecc), e quindi rendere opportune modifiche nullability.