Scegliamo di eseguire lo script di tutto, incluse tutte le procedure memorizzate e le modifiche allo schema. Non sono necessari strumenti wysiwyg e programmi di 'sincronizzazione' fantasiosi.
Le modifiche allo schema sono facili, tutto ciò che devi fare è creare e mantenere un unico file per quella versione, incluse tutte le modifiche allo schema e ai dati. Questo diventa il tuo script di conversione dalla versione x alla x+1. Puoi quindi eseguirlo su un backup di produzione e integrarlo nella tua "costruzione quotidiana" per verificare che funzioni senza errori. Tieni presente che è importante non modificare o eliminare lo schema già scritto/sql di caricamento dati poiché potresti finire per interrompere qualsiasi sql scritto in seguito.
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
Per le stored procedure, scegliamo un singolo file per sproc e utilizza il modulo drop/create. Tutte le stored procedure vengono ricreate durante la distribuzione. Lo svantaggio è che se una modifica è stata eseguita al di fuori del controllo del codice sorgente, la modifica viene persa. Allo stesso tempo, questo è vero per qualsiasi codice, ma il tuo DBA deve esserne consapevole. Ciò impedisce davvero alle persone al di fuori del team di confondere le tue procedure archiviate, poiché le loro modifiche vengono perse in un aggiornamento.
Utilizzando SQL Server, la sintassi è simile a questa:
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
L'unica cosa rimasta da fare è scrivere un programma di utilità che raccolga tutti i singoli file e crei un nuovo file con l'intero set di aggiornamenti (come un unico script). A tale scopo, prima aggiungendo le modifiche allo schema, quindi ricorrendo alla struttura della directory e includendo tutti i file di stored procedure.
Come vantaggio dello scripting di tutto, diventerai molto più bravo a leggere e scrivere SQL. Puoi anche rendere l'intero processo più elaborato, ma questo è il formato di base su come controllare il codice sorgente di tutti gli sql senza alcun software speciale.
addendum:Rick ha ragione sul fatto che perderai le autorizzazioni sulle procedure memorizzate con DROP/CREATE, quindi potrebbe essere necessario scrivere un altro script per riattivare autorizzazioni specifiche. Questo script di autorizzazione sarebbe l'ultimo da eseguire. La nostra esperienza ha riscontrato più problemi con la semantica dei versi ALTER DROP/CREATE. YMMV
