Migliori pratiche di distribuzione del database

Question

Per lo più cambiamo tabelle di database esistenti, stored procedure, funzioni o parametri nelle tabelle per aggiornamenti software/correzioni di errori. E quando è il momento di implementare le nostre modifiche in un altro ambiente come la produzione o la pre-produzione, alcune parti delle nostre modifiche al database vengono dimenticate.

Nella nostra azienda, alcuni sviluppatori utilizzano un'applicazione di analisi delle differenze del database per scoprire le differenze tra ambiente di test e di produzione. Alcuni sviluppatori memorizzano t-sql di ogni cambiamento che hanno fatto su db, come me.

Mi chiedo cosa si sta facendo per distribuire le modifiche db all'ambiente di produzione. Perché scegli così? O cosa si deve fare?

Grazie per le risposte!

Answer 1

Abbiamo il nostro db sotto il controllo del codice sorgente. Eventuali modifiche sono tracciate in questo modo. Qualsiasi altra cosa sarebbe un incubo.

Jeff ha un articolo su di esso troppo - http://blog.codinghorror.com/get-your-database-under-version-control/

seconda della configurazione e del database, la Pubblicazione guidata database - http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard - può essere veramente utile.

Answer 2

Scripting e memorizzazione di tutte le modifiche apportate in SQL è il modo migliore IMO.

Answer 3

In un progetto, ho tutte le mie modifiche DB negli script DDL. Questi script contengono le istruzioni SQL necessarie per aggiornare il DB a una determinata versione. Il nome file dello script contiene anche il numero di versione del DB a cui verrà aggiornato il DB (_versionnumber.sql)

Accanto a ciò, ho una piccola applicazione che aggiorna il DB all'ultima versione, eseguendo questi file di script nell'ordine corretto (dalla versione corrente del DB all'ultimo file di script).

Per i nuovi progetti, ora utilizzo Migrator.NET. Questo framework consente di scrivere le modifiche del DB in classi C#. Il framework ha un'applicazione console con la quale è possibile eseguire le modifiche al DB, ed è anche possibile utilizzarlo con msbuild.

Answer 4

Ogni oggetto di database deve essere memorizzato in un file separato nel sistema di controllo versione. sistema di controllo versione potrebbe contenere file come in questo esempio:

|- tables 
    |- employees.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

Ogni volta che si modifica un oggetto DB, allora si deve anche modificare il file (DDL) SQL appropriato nel sistema di controllo versione. Ad esempio, se si modifica il pacchetto contract_api, si aggiorna il file contract_api.sql. Poiché questo file è stato modificato, può essere installato, ad esempio, da un motore di integrazione continuo.

MA, come sai, ci sono script DDL, che non possono essere eseguiti due volte. Ad esempio, lo script 'CREATE TABLE mytable ...' può essere eseguito solo una volta. E se il tuo sistema è già in produzione, non puoi permetterti di utilizzare l'istruzione 'DROP TABLE mytable' nell'intestazione dello script 'CREATE TABLE ...'. Pertanto per i sistemi di produzione è necessario creare i cosiddetti script delta che forniranno solo le modifiche. In questo caso potresti semplicemente creare un nuovo file chiamato employees_upd01.sql che contiene l'istruzione 'ALTER TABLE mytable ADD COLUMN ...'.

Dopo qualche tempo il repository potrebbe essere la seguente:

|- tables 
    |- employees.sql 
    |- employees_upgr20091001.sql 
    |- employees_upgr20091004.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

E questo è OK, perché: 1) quando è necessario consegnare modifiche incrementali di oggi a base di dati - si distribuiscono i file che sono stati modificati oggi 2) se è necessario distribuire un'installazione pulita del sistema - si eseguono tutti gli script in ordine, ad es. prima employees.sql, quindi employees_upgr20091001.sql, ecc

Come ogni oggetto DB è in un file separato nel sistema di controllo di versione, si ha un buon controllo su tutte le modifiche.