Come mantenere le procedure memorizzate e altri script nel repository SVN/Altro?

Question

Qualcuno può fornire alcuni esempi reali su come conservare al meglio i file di script per visualizzazioni, procedure memorizzate e funzioni in un repository SVN (o altro).

Ovviamente una soluzione è avere i file di script per tutti i diversi componenti in una directory o più da qualche parte e utilizzare semplicemente TortoiseSVN o simili per mantenerli in SVN, quindi ogni volta che è necessario apportare una modifica carico lo script in Management Studio ecc. .Non lo voglio davvero.

Ciò che preferirei davvero è una sorta di script batch che posso eseguire periodicamente (di notte?) che esporti tutte le procedure/visualizzazioni memorizzate ecc. Che sono cambiate in un determinato periodo di tempo e quindi le impegni su SVN.

Idee?

Answer 1

A me sembra che tu non voglia usare correttamente il Controllo revisioni.

Ovviamente una soluzione è avere i file di script per tutti i diversi componenti in una directory o più da qualche parte e semplicemente usando TortoisVN o simili per tenerli in SVN

Questo è ciò che dovrebbe essere fatto.Avresti la tua copia locale su cui stai lavorando (Sviluppo di nuovo, Ottimizzazione di vecchio, ecc.) e una volta terminati i singoli componenti/procedure/ecc., li impegneresti individualmente fino a quando non dovrai ricominciare il processo.

Commettere codice a metà solo perché è passato "X" tempo dall'ultima volta che è stato eseguito il commit è sciatto e garantisce che causerà dolore a chiunque altro utilizzi il repository.

Answer 2

Trovo che sia meglio trattare le procedure memorizzate come qualsiasi altro codice compilabile:Il codice risiede nel repository, lo controlli per apportare modifiche e lo carichi nel tuo strumento di sviluppo per compilare o distribuire il codice.

Answer 3

È possibile creare un file batch e pianificarlo:

• elimina il contenuto della directory degli script
• usando qualcosa di simile EsportaSQLScript per esportare tutti gli oggetti in script/script
• commit svn

Notare che:Che anche se avrai gli oggetti sotto il controllo del codice sorgente, non avrai i dati o la loro progressione (è un campo rinominato o 1 nuovo campo e 1 eliminato?).

Questo approccio va bene per mantenere la cronologia delle modifiche.Ma, ovviamente, non dovresti mai impegnarti automaticamente nella "build di produzione" (a meno che non ti piacciano le build non funzionanti).

Anche se non l'hai chiesto tu:Inoltre, questo approccio non produrrà una serie di script che aggiorneranno un DB corrente.Avrai solo script di creazione iniziale.La registrazione della progressione dei dati e la creazione di script di aggiornamento vanno oltre i sistemi di controllo del codice sorgente di base.

Answer 4

Lo consiglierei Redgate SQL Compare per questo: consente di confrontare le versioni del database e generare script di modifica; è anche abbastanza facilmente scrivibile.

Answer 5

In base alla tua domanda estesa, vuoi davvero utilizzare i trigger DDL.Guardare Questo articolo che descrive in dettaglio come creare un sistema di registro delle modifiche per il tuo database.

Answer 6

Non sono sicuro della fascia di prezzo, tuttavia DB Fantasma potrebbe essere un'opzione per te.

Non lavoro per questa azienda (né possiedo il prodotto) ma nella mia ricerca sullo stesso problema, questo prodotto sembrava piuttosto promettente.

Answer 7

Avrei dovuto essere un po' più descrittivo.Il database in questione è per un sistema ERP interno e quindi non abbiamo molte versioni del nostro database, solo Produzione/Test/Sviluppo.Quando abbiamo effettuato una richiesta di modifica, qualche nuova funzionalità fantasiosa o qualcosa del genere, eseguiamo semplicemente uno script o una serie di script per aggiornare le procedure in questione sul database di Testing, se va tutto bene, allora facciamo lo stesso con la Produzione.

Quindi non sto cercando uno script di schema completo di per sé, ma solo qualcosa che possa tenere traccia delle varie modifiche alle procedure memorizzate nel tempo.Ad esempio, PROCESS_INVOICE fa cose.Viene aggiornato in qualche modo minore a marzo.Qualche tempo dopo, diciamo a maggio, si scopre che in rari casi i clienti ricevono una doppia fattura (o qualche altro caso folle).Mi piacerebbe poter vedere cosa è successo nel tempo a questa procedura.Attualmente non ho il modo in cui è impostato l'ambiente di sviluppo, cosa che sto cercando di cambiare.

Answer 8

Posso consigliare DBPro che fa parte di Visual Studio Team Edition.Lo utilizzo da alcuni mesi per archiviare tutte le parti del database in Team Foundation Server, nonché per la distribuzione e il confronto di database, ecc.

Naturalmente, come ha detto qualcun altro, dipende dall'ambiente e dalla fascia di prezzo.

Answer 9

Ho scritto un'utilità per scaricare tutte le parti rilevanti del mio db in una struttura di directory su cui utilizzo SVN.Non sono mai riuscito a provare a incorporarlo nel Manager ma, se sei interessato, è qui: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

È gratuito e, poiché lo eseguo regolarmente, sai che eventuali bug vengono risolti rapidamente.

Answer 10

Puoi sempre provare a integrare SourceSafe con SQL Server.Ecco un avvio rapido: collegamento .Per lavorare con esso devi avere Managment Studio Developers Edition.