Quando si sviluppa un'applicazione con molte stored procedure, è necessario memorizzarle in una sorta di sistema di controllo delle versioni di origine (come SFS sicuro, TFS, SVN)? Se è così, perché? E c'è un modo front-end conveniente per farlo con SQL Server Management Studio?È necessario archiviare le stored procedure SQL nel controllo del codice sorgente?
Sì. Tutto il codice deve essere memorizzato nel controllo sorgente.
In poche parole, il codice è codice e gli errori si verificano. È bello poter tornare indietro e vedere cosa è cambiato nel tempo ed essere in grado di tornare a quei cambiamenti.
Dobbiamo aggiungerlo manualmente a un sistema di controllo del codice sorgente, ma è possibile creare componenti aggiuntivi per il server Sql del sistema di gestione. Non ne ho mai creato uno per aggiungerlo automaticamente al controllo del codice sorgente, ma suppongo che sia possibile. Inoltre, tutto il codice è memorizzato in tabelle sql, quindi in teoria è possibile creare un processo o qualcosa per passare attraverso le tabelle e recuperare tutto il codice e commetterlo automaticamente.
Aggiornamento: Scriverò sempre codice aggiuntivo per verificare se il codice esiste e se non crea una procedura di riempimento e quindi lo script effettivo esegue e modifica la procedura.
IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE
id = OBJECT_ID(N'[dbo].[SomeStoredProcedure]') AND
OBJECTPROPERTY(id,N'IsProcedure') = 1)
EXEC sp_executesql N'CREATE PROCEDURE [dbo].[SomeStoredProcedure] AS
SELECT ''SPROC Template'''
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE SomeStoredProcedure
Facendo una goccia e ricreare rimuoverà tutte le autorizzazioni degli utenti che avete impostato per farlo.
Si dovrebbe.
A mia conoscenza, non esiste uno strumento di questo tipo per automatizzare questo processo. Almeno cinque anni fa, quando stavo considerando di costruirne uno, non sembrava esserci alcuna competizione.
Ci sono strumenti là fuori, e lo studio visivo ha alcune funzionalità incorporate. Tuttavia, è quasi universalmente inadeguato. Vorremmo comprare una licenza di codice souce per un prodotto di terze parti e ottimizzato gli extra necessari per farlo funzionare. – JohnFx
conserviamo i nostri procs in Subversion, tutto il codice SQL tra cui DDL dovrebbe essere in una sorta di repository di controllo del codice sorgente
SP e schemi di tabella per quella materia sono tutte le attività che dovrebbero essere sotto controllo di versione. In un mondo perfetto, il DB verrebbe creato dagli script, inclusi i dati di test, come parte del processo CI. Anche se non è così, avere un DB/sviluppatore è un buon modello da seguire. In questo modo le nuove idee possono essere provate in una sandbox locale senza impatto su tutti, una volta verificata la modifica è possibile effettuare il check-in.
Management Studio può essere collegato al controllo del codice sorgente, anche se non ho esperienza di fare Questo. Abbiamo sempre tracciato il nostro SP/schema come file. Lo studio di gestione può generare automaticamente script di modifica, che sono molto utili, dato che il drop/ricreazione delle tabelle può essere troppo pesante per qualsiasi tabella contenente dati.
Sicuramente sì. Quindi la domanda diventa come li memorizzi nel controllo del codice sorgente. Eliminate e ricreate la procedura memorizzata o semplicemente modificate, aggiungete le autorizzazioni alla fine dello script o in uno script separato. C'era un post su Coding Horror un po 'indietro sul tema che ho trovato interessante. Is Your Database Under Version Control?
I proc SQL richiedono sicuramente la stessa sicurezza/i vantaggi del controllo della versione del resto del codice nel progetto.
Si consiglia di archiviarli. Non si sa mai quando è necessario eseguire il rollback, o scavare nella logica che si è rimosso.
Ecco un buon modo per acquisire facilmente i Processi memorizzati in file che è possibile inserire in qualsiasi controllo sorgente desiderato.
Get your database under version control. Controlla la serie di post di Scott Allen.
Quando si parla di controllo della versione, il database è spesso un cittadino di secondo o terzo livello. Da quello che ho visto, i team che non avrebbero mai pensato di scrivere codice senza il controllo della versione in un milione di anni - e giustamente - possono in qualche modo essere completamente ignari dell'esigenza di controllo della versione attorno ai database critici su cui si basano le loro applicazioni. Non so come puoi definirti un ingegnere del software e mantenere una linea diritta quando il tuo database non ha esattamente lo stesso livello rigoroso di controllo del codice sorgente del resto del tuo codice. Non lasciare che questo accada a te. Ottieni il tuo database sotto controllo di versione.
ASSOLUTAMENTE POSITIVAMENTE SENZA QUESTIONE NESSUNA ECCEZIONE IN TUTTE LE PERPETUITÀ IN TUTTO L'UNIVERSO SI!
sooo ... quello che stai dicendo è che pensi sia una buona idea? :) – kemiller2002
.. non mettere troppo bene un punto su di esso. – ConcernedOfTunbridgeWells
Ma ti senti fortemente in un modo o nell'altro? :) – NTDLS
Come altri hanno già detto, sì, dovrebbero essere.
Non conosco un modo semplice per farlo con SQL Server Management Studio, ma se si utilizza anche Visual Studio, i progetti di database sono un ottimo modo per gestirlo.
Certo che dovresti.
In MS SQL 2008, è possibile farlo right from Management Studio.
Assolutamente. Positivamente.
Un set di SP è un'interfaccia, che è probabile che venga modificata più frequentemente rispetto alle modifiche strutturali. E poiché gli SP contengono la logica aziendale, le modifiche devono essere memorizzate nel controllo di versione per tracciare le modifiche e le regolazioni della logica.
La memorizzazione di questi nel controllo della versione è un sintomo della maturità organizzativa a livello di codice ed è una best practice.
La memorizzazione di stored procedure è una grande idea. È un dolore però. Come fai a portare tutta quella roba in sovversione? Puoi farlo manualmente, ma è noioso e alla fine non lo fai affatto.
Uso uno strumento da subsonic project.
sonic.exe version /server servername /db databasename /out outputdirectory
Questo comando salva tutto in 2 file di testo. Uno contiene lo schema del database, i proc memorizzati, gli account utente, i vincoli e le chiavi primarie. L'altro contiene i dati.
Ora che si dispone di questi due file è possibile utilizzare subversion (cvs, source safe) per spostarlo nel controllo del codice sorgente.
Maggiori informazioni per using The Command Line Tool (SubCommander)
SQL è il codice. Tutto il codice appartiene al controllo del codice sorgente.
Questo è tutto.
Se non riesci a spiegarlo in modo semplice, non lo capisci abbastanza bene. Einstein – SheldonH
Esistono metodi in SMO per generare script se si preferisce codificare il proprio strumento di scripting.
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated
Se non si utilizza di gestione patrimoniale al fianco di controllo del codice sorgente, allora io dico buttare tutto in controllo del codice sorgente. Immagini, documenti di parole, l'intera shebang. Non può perderlo, può sempre invertire le eventuali modifiche e se una qualsiasi macchina si arresta, non si perde nulla.
Più decisamente.
E aggiungerei le definizioni di tabella inclusi indici, chiavi, ecc. E tutti i dati di "ricerca" che non dovrebbero essere creati durante la vita dell'app. –