it-swarm.it

Perché dovrei usare Visual Studio 2010 su SSMS per lo sviluppo del mio database?

Visual Studio 2010 introduce progetti di database e un'intera gamma di funzionalità correlate che presumibilmente facilitano lo sviluppo del database. Ho usato SQL Server Management Studio (SSMS) per molti anni per sviluppare il mio database senza problemi.

  • Perché dovrei preoccuparmi di VS2010 quando SSMS funziona per me? Cosa fa meglio di SSMS?
  • Ma forse la mia premessa è errata e SSMS supera ancora VS per lo sviluppo del database. In tal caso, in quali modi specifici è vero?
42
Nick Chammas

In realtà ero un po 'deludente con VS2010, a dire il vero. Penso che uno script di tabella di vecchia scuola e file per le procedure memorizzate siano più facili da lavorare. Se è necessaria la gestione dello schema, è possibile ottenere Redgate SQL Compare Pro per alcune centinaia di dollari.

Se hai davvero bisogno di uno strumento di modellazione di database, Powerdesigner o persino Erwin fanno un lavoro molto migliore, anche se non sono particolarmente economici.

Anche se preferisco SSMS ho usato entrambi. Alcuni pro e contro:

  • SSMS ha un'interfaccia utente che "funziona" bene per lo sviluppo di SQL. Costruire e usare gli script di creazione è molto più conveniente dei cerchi VS2010 che ti costringono a saltare. Molto, molto più flessibile (+ SSMS).

  • VS2010 ha una gestione di schema di base (ovvero differenza/generazione di script di patch) (+ VS2010). Tuttavia non è poi così buono e ha alcuni difetti. Ad esempio, corrisponde ai vincoli sul nome. Se sono presenti vincoli di controllo o predefiniti su una colonna senza denominarli, SQL Server genera un nome casuale dietro le quinte. Ciò confonderà VS2010 se si installa lo script su una macchina diversa poiché i vincoli potrebbero avere nomi diversi. Redgate è più economico e migliore. (+ VS2010, ma imperfetto).

  • VS2010 è davvero maldestro: è necessario disporre di un file per ogni tabella o altro oggetto DB. Fondamentalmente devi fare le cose nel modo VS2010, il che è abbastanza ingombrante. (- VS2010)

  • VS2010 è anche un po 'fragile e l'integrazione del controllo del codice sorgente è instabile. Anche su un semplice database ogni tabella, vincolo, stored procedure, indice e altri oggetti di database sono i propri file. I file vengono sempre aggiunti al progetto, molto più velocemente di un tipico progetto di programmazione con (diciamo) C #. Con una concorrenza ottimistica ha la tendenza a eliminare silenziosamente i file dal progetto mentre i check-in non sono sincronizzati. Anche con una buona disciplina di squadra, il feedback dell'interfaccia utente sullo stato è molto scarso. Questo sarebbe un disastro su un modello complesso. (-VS2010 - Quasi considererei questo un difetto di grande spettacolo per un grande progetto).

  • SSMS viene fornito con SQL Server - non può battere il prezzo (+ SSMS).

  • VS2010 non ha ancora un repository adeguato come (diciamo) PowerDesigner o Oracle Designer. Non è possibile interrogare facilmente il modello di dati senza installarlo in un database. (- VS2010).

Nel complesso, classificherei VS2010 su un B-. Era goffo su un progetto di database relativamente semplice con due tabelle dei fatti e circa 15 dimensioni.

Il più grande modello di dati che abbia mai fatto è stato per un sistema di gestione dei casi giudiziari, che aveva circa 560 tavoli. Non consiglierei VS2010 per un progetto di quelle dimensioni (l'ho fatto su Oracle Designer). In sostanza sta cercando di essere intelligente e il paradigma non funziona davvero così bene. Stai meglio con uno strumento di modellazione all'avanguardia come PowerDesigner o semplicemente usando manualmente gli script di tabella.

SSMS è semplice e affidabile ma manuale. Hai un controllo praticamente infinito su come vuoi gestire il modello. Combinalo con un gestore di schemi come Redgate SQL Compare e forse uno strumento di modellazione decente come PowerDesigner e avrai un pacchetto molto migliore di VS2010.

Riepilogo Non sono sicuro di poter citare eventuali caratteristiche o vantaggi killer a parte (forse) l'integrazione con soluzioni VS contenenti altri progetti. Se hai già VS2010 premium o ultimate, otterrai uno strumento di sviluppo del database in qualche modo difettoso inserito nella tua catena di strumenti .Net. Integrerà i progetti DB nella soluzione VS, quindi è possibile utilizzarlo almeno per creare script di distribuzione sproc.

Tuttavia, VS non ha uno strumento di modellazione di cui parlare, quindi PowerDesigner o persino Erwin è meglio su questo punto. La gestione dello schema di Redgate è molto migliore e SQL Compare Pro è abbastanza economico (circa £ 400 IIRC). IMHO SSMS funziona molto meglio per lo sviluppo di T-SQL ma puoi sicuramente farlo con VS2010.

VS2010 premium non è molto più economico di uno strumento di modellazione di database all'avanguardia e VS2010 ultimate è almeno altrettanto costoso. A scapito della stretta integrazione con il tuo progetto VS potresti probabilmente fare di meglio con strumenti di terze parti.

n'alternativa

Immagino che non si debba scartare troppo VS2010 senza suggerire almeno un'alternativa e delinearne i pro ei contro. Ai fini di questo assumerò un grande progetto. Anche se principalmente lavoro A/P in questi giorni, sono stato coinvolto in un progetto di oltre 100 anni di personale in cui ho fatto il modello di dati (e alcuni lavori di sviluppo) e un paio di altri nella gamma di 10 anni di personale, dove ho principalmente lavorato come analista o sviluppatore. Attualmente lavoro principalmente su sistemi di data warehouse, ma i progetti più grandi erano principalmente applicazioni. Sulla base delle mie esperienze con vari strumenti, ecco alcuni suggerimenti per una catena di strumenti alternativa:

  • VS2010 professionale o superiore. È possibile che si desideri utilizzare le funzionalità di gestione dei progetti premium o ultimate.
  • Subversion, AnkhSVN e TortoiseSVN - Meglio di TFS ogni giorno e gioca bene con VS. È anche abbastanza suscettibile di coltivare nei repository locali per flussi di lavoro di sviluppo simultanei.
  • SSMS per lo sviluppo di T-SQL - Gestione del progetto e SC non è così buona ma funziona bene per il lavoro di sviluppo del DB.
  • Progetto VS2010 DB per il tracciamento dei file sproc: leggermente maldestro se si utilizza SSMS ma funziona correttamente. Inoltre genererà script di distribuzione.
  • PowerDesigner: il modo migliore per modellare un database e gestire gli elementi dello schema DB. Fa anche UML se vuoi entrare pesantemente in MDA. Se si desidera guidare la progettazione del proprio DB da un modello a oggetti, è possibile prendere in considerazione Sparx EA. Fa il miglior lavoro di Meta CASE (metamodello estensibile) di qualsiasi strumento CASE che abbia mai visto, anche se la sua modellazione di database lascia a desiderare.
  • SQL Compare pro: utilizzare questa opzione per generare script di patch DB o per testare script di patch manuali (vedere 1 di seguito).
  • Framemaker - Funzionalità di groupware molto più stabili e migliori di Word se hai più analisti che lavorano su una specifica. Supporta anche l'inclusione condizionale, quindi puoi avere le versioni versionate di una specifica con le modifiche WIP nascoste. MIF e MML rendono abbastanza semplice l'integrazione di documenti API e dizionari di dati nei documenti delle specifiche. È abbastanza utile farlo poiché puoi quindi fare un riferimento incrociato nelle specifiche. Le ancore testuali per etichette rendono stabili i riferimenti incrociati tra reimportazioni. È inoltre possibile utilizzare TCS per eseguire il single-source del documento in PDF, HTML e output CHM.
  • Tracciatore di problemi open-source - Molti buoni open-source (ad esempio TRAC, Bugzilla per citarne un paio che ho usato). Quelli open-source sono più facili da modificare o integrare in un flusso di lavoro personalizzato e non puoi battere il prezzo.
  • NUnit o altri strumenti di test - qualunque sia lo strumento di test automatizzato più adatto alle tue esigenze.
  • Tutto tranne il progetto MS - Considerato dannoso. Il progetto MS ha uno sguardo molto interiore e impone i piani di progetto in un modello che non rappresenta efficacemente incertezza, rischio o dipendenze da parti interessate o altre terze parti (vedere 2 sotto).

Pro: Migliore modellizzazione del database e gestione dello schema rispetto a VS2010, migliore sistema di controllo della versione, più facile personalizzare il flusso di lavoro di compilazione e progetto, migliore gestione delle specifiche e della documentazione.

Contro: Più sforzi per integrare gli strumenti, limitata integrazione del DB nel processo di compilazione.

Presupposti: Presuppone che il controllo del processo di modifica/rilascio sia più importante della gestione delle versioni automatizzata o strettamente integrata per gli schemi DB. Presuppone inoltre che la gestione automatizzata dello schema DB non sia affidabile al 100%.

Non terribilmente high-tech o perfettamente integrato, ma per un progetto complesso probabilmente sei più interessato al controllo rispetto alle graziose funzionalità automatizzate. Direi che stai meglio con una serie dei migliori strumenti di allevamento e qualsiasi costruzione di birra fatta in casa e test di scripting sia necessario per integrarli. Basta provare a mantenere la build (a) relativamente semplice da capire e (b) completamente automatizzata.

  1. QA su patch DB. Su uno schema di grandi dimensioni potrebbe essere necessario disporre di un processo di patching manuale per i sistemi live, in particolare se le patch prevedono la migrazione dei dati. Ad esempio, può essere desiderabile disporre di script roll-forward e roll-back per supportare il backup di una modifica, se necessario. In questo caso, sarà necessario disporre di una funzione per verificare che la patch funzioni correttamente. Se si gestisce lo schema del database in un repository, è possibile testare gli script impostando prima dei database e generando un database di riferimento dal repository. L'esecuzione dello script di patch sul database precedente dovrebbe sincronizzarlo con il modello di repository. Uno strumento di confronto dello schema può essere utilizzato per testare questo.

  2. Ultimamente ho svolto molto più lavoro di data warehouse e integrazione rispetto allo sviluppo di applicazioni su misura, quindi nella maggior parte dei casi lo incontro più spesso di un team di sviluppo. Tuttavia, gli strumenti e le metodologie di gestione dei progetti fanno un pessimo lavoro di gestione delle parti interessate esterne. In un progetto di integrazione come un data warehouse voglio davvero vedere uno strumento di gestione del progetto che spinge davvero le dipendenze esterne (cioè quelle che non controllo) di fronte alla gestione del programma. In qualsiasi progetto di integrazione non banale, le dipendenze esterne sono di gran lunga i principali fattori di perdita di tempo.

Sto giocando con come strutturare una risposta a questa domanda da quando è stata originariamente pubblicata. Questo è difficile poiché il caso di VS2010 non riguarda la descrizione delle caratteristiche e dei vantaggi dello strumento. Si tratta di convincere il lettore a cambiare radicalmente il proprio approccio allo sviluppo del database. Non facile.

Ci sono risposte a questa domanda da parte di professionisti del database esperti, con un mix di background che comprende DBA, sviluppatore/dba e entrambi OLTP e data warehousing. Non è fattibile per me affrontare questo per ogni aspetto del database sviluppo in una sola seduta, quindi proverò a presentare un caso per uno scenario particolare.

Se il tuo progetto soddisfa questi criteri, penso che ci sia un caso convincente per VS2010:

  • Il tuo team sta utilizzando VS2010 per lo sviluppo di applicazioni.
  • Il tuo team sta usando TFS per il controllo del codice sorgente e la gestione delle build.
  • Il tuo database è SQL Server.
  • Il tuo team ha già o è interessato a test automatici VS.

Se stai valutando VS2010 per lo sviluppo del database, la tua bibbia sarà la Guida del database di Visual Studio dalla Visual Studio ALM Rangers . Eventuali citazioni che seguono che non hanno riferimenti verranno da questo documento.

Andiamo quindi ...

Perché il processo di sviluppo del database è diverso dallo sviluppo dell'applicazione?

Dati. Se non fosse per quei dati fastidiosi, lo sviluppo del database sarebbe un gioco da ragazzi. Potremmo semplicemente DROP tutto su ogni versione e dimenticare questa problematica gestione delle modifiche.

L'esistenza dei dati complica il processo di modifica del database poiché i dati vengono spesso migrati, trasformati o ricaricati quando le modifiche sono introdotte da sforzi di sviluppo dell'applicazione che influenzano la forma delle tabelle del database o altri schemi di dati. Durante questo processo di modifica, i dati sulla qualità della produzione e lo stato operativo devono essere protetti da modifiche che potrebbero comprometterne l'integrità, il valore e l'utilità per l'organizzazione.

Cosa c'è che non va in SSMS?

Si chiama SQL Server Management Studio per un motivo. Come strumento autonomo, non è pratico gestire i tuoi sforzi di sviluppo if seguirai le migliori pratiche accettate.

Solo con gli script, per applicare in modo significativo pratiche consolidate di controllo del codice sorgente al tuo sviluppo, dovrai mantenere sia le definizioni degli oggetti (ad esempio uno script CREATE TABLE), sia gli script di modifica (ad esempio ALTER TABLE) E lavorare sodo per assicurarti che rimangano sincronizzati.

La catena di versioni per le modifiche a una tabella diventa piuttosto stupida abbastanza rapidamente. Un esempio molto semplicistico:

-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))

-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))

-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

Dalla versione 3, lo script di modifica del database contiene:

ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

Se la versione live di questo database è la versione 1 e la nostra prossima versione è la versione 3, lo script seguente sarebbe tutto ciò che era necessario ma invece verranno eseguite entrambe le istruzioni ALTER.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

Gli sprint di 5 anni di 4 settimane aggiungono alcuni script di versioni divertenti e richiedono una gestione aggiuntiva da parte dell'uomo per ridurre al minimo l'impatto sui tempi di implementazione.

Quindi c'è qualcosa che non va in SSMS? No, fa bene a cosa serve, amministrare e gestire SQL Server. Ciò che non pretende nemmeno di fare è aiutare uno sviluppatore di database con il compito (a volte) molto complesso di gestire il cambiamento.


Se non riesci a creare tutte le versioni del database dall'origine e passare a qualsiasi versione futura, il controllo del codice sorgente è interrotto. Se non la pensi così, chiedi a Eric Sink .


Che dire di SSMS + <- inserire lo strumento di confronto degli schemi ->?

Questo è sicuramente un passo nella giusta direzione e toglie gran parte dello sforzo manuale richiesto per mantenere gli script. Ma (ed è un grande ma), in genere ci sono passaggi manuali coinvolti.

I popolari strumenti di confronto degli schemi possono essere completamente automatizzati e integrati nel processo di compilazione. Tuttavia, nella mia esperienza, la pratica più comune è che un confronto venga eseguito manualmente, gli script risultanti vengono controllati, controllati nel controllo del codice sorgente, quindi eseguiti manualmente per la distribuzione. Non bene.

Ogni volta che noi umani fallibili dobbiamo essere coinvolti nel processo di costruzione o dispiegamento, introduciamo dei rischi e rendiamo il processo non ripetibile.

Se tu e il tuo team siete tra i pochi ad avere un confronto e una distribuzione degli schemi completamente automatizzati, vi saluto! Ragazzi, avete maggiori probabilità di essere aperti ai vantaggi che VS2010 ha da offrire come:

  • Hai già accettato che i passaggi manuali sono pericolosi.
  • Vedi il valore dell'automazione.
  • Sei disposto a investire il tempo necessario per farlo funzionare.

Se non è possibile creare una build in un singolo passaggio o distribuire in un singolo passaggio, il processo di sviluppo e distribuzione è interrotto. Se non la pensi così, chiedi a Joel Spolsky .


Perché VS2010?

La domanda posta da @NickChammas è alla ricerca di funzionalità killer che dimostrino perché VS2010 è un punto di svolta per lo sviluppo di database. Non credo di poter presentare il caso su tale base.

Forse comicamente, dove altri vedono difetti in questo strumento vedo forti ragioni per l'adozione:

  • Dovrai cambiare il tuo approccio.
  • Tu e il tuo team sarete costretti a lavorare in modo diverso.
  • Dovrai valutare l'impatto di ogni modifica, a lungo, in dettaglio.
  • Sarai guidato a fare ogni cambiamento idempotente .

Se sei l'unico DBA di un progetto, gestendo tutte le modifiche al database, questo ragionamento deve sembrare ridicolo al limite dell'assurdo. Se tuttavia ritieni che @BrentOzar abbia un punto e una delle nuove regole è che Everybody's the DBA , dovrai controllare le modifiche al database in modo che tutti gli sviluppatori del team possano lavorare.

L'adozione di progetti di database può richiedere un cambiamento mentale ( le vecchie abitudini sono difficili da spezzare ) per alcuni sviluppatori o almeno un cambiamento nel processo o nei flussi di lavoro. Gli sviluppatori che hanno sviluppato applicazioni di database in cui il database di produzione rappresenta la versione corrente del database dovranno adottare un approccio basato sul codice sorgente in cui il codice sorgente diventa il veicolo su cui viene apportata la modifica ai database . Nei progetti di database di Visual Studio, il progetto e il codice sorgente sono "Una versione della verità" per lo schema del database ed è gestito usando flussi di lavoro SCM probabilmente già utilizzati dallo sviluppatore o dall'organizzazione per altre parti del loro stack di applicazioni. Per i dati, il database di produzione rimane la sua "Una versione della verità" come dovrebbe essere.

Siamo arrivati ​​al cambiamento fondamentale necessario per adottare con successo l'approccio VS2010 allo sviluppo del database ...

Tratta il tuo database come codice

Non è più necessario modificare il database live. Ogni modifica del database seguirà lo stesso modello di una modifica dell'applicazione. Modifica sorgente, compilazione, distribuzione. Questo non è un cambio temporaneo di direzione da parte di Microsoft, questo è il futuro di SQL Server . Database come codice è qui per rimanere.

Lo sviluppatore del database definisce la forma dell'oggetto per la versione dell'applicazione, non come mutare l'oggetto esistente nel motore di database nella forma desiderata. Potresti chiederti: come viene distribuito su un database che contiene già la tabella dei clienti? È qui che entra in gioco il motore di distribuzione. Come accennato in precedenza, il motore di distribuzione prenderà la versione compilata dello schema e la confronterà con una destinazione di distribuzione del database. Il motore di differenziazione produrrà gli script necessari per aggiornare lo schema di destinazione in modo che corrisponda alla versione che si sta distribuendo dal progetto.

Sì, ci sono altri strumenti che seguono un modello simile e per i progetti al di fuori dei vincoli che ho posto sulla mia risposta, valgono la stessa considerazione. Ma, se lavori con Visual Studio e Team Foundation Server ALM, non penso che possano competere.

Cosa c'è che non va nei progetti di database VS2010?

Modifica: Allora che senso hai?

@AndrewBickerton ha menzionato in un commento che non ho risposto alla domanda originale, quindi proverò a riassumere "Perché dovrei usare Visual Studio 2010 su SSMS per lo sviluppo del mio database?" Qui.

  • SSMS non è uno strumento di sviluppo del database. Sì, puoi sviluppare TSQL con SSMS ma non fornisce le funzionalità rich IDE di VS2010.
  • VS2010 fornisce un framework per trattare il database come codice.
  • VS2010 porta analisi del codice statico nel codice del database.
  • VS2010 offre gli strumenti per automatizzare completamente il ciclo di build-deploy-test.
  • SQL2012 e Visual Studio vNext estendono le capacità dei progetti di database. Conosci subito VS2010 e avrai un vantaggio sugli strumenti di sviluppo del database di prossima generazione.
19

VS potrebbe apparire fantastico se non conosci SSMS o hai utilizzato strumenti di terze parti. Le lacune in VS si distinguono se si utilizzano gli strumenti Red Gate per il confronto di schemi ecc. E anche i plug-in SSMS gratuiti.

I bit di controllo del codice sorgente sono fuorvianti: ciò che si trova nel database di produzione è la tua copia di riferimento. Non quello che lo sviluppatore sta usando. Vedere

7
gbn

Uso ampiamente Visual Studio (beh, BIDS) per la progettazione di report SSRS e pacchetti SSIS. Nemmeno io potrei fare molto bene in Management Studio. Visual Studio è un ambiente di sviluppo molto più completo e integrato e si collega molto meglio ai sistemi di controllo del codice sorgente. E tutto ciò si riflette nel prezzo!

6
Peter Schofield

Ad essere sincero, il mio voto va direttamente a SQL Server Management Studio per la progettazione, lo sviluppo e (ovviamente) l'amministrazione del database. È solo più facile da scrivere:

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

Quindi fare clic in tutti i posti giusti. SSMS è un ottimo layout e un vero spasso in cui lavorare. E io sono uno sviluppatore di software .NET per natura. Ma quando si tratta di progettazione e codifica di database, sceglierò SSMS 11 volte su 10.

6
Thomas Stringer

Non esistono best practice, ma con il progetto di database VS 2010 e il controller del codice sorgente (VSS 2010, Subversion, ecc.) È possibile eseguire la versione del database.

Ti consiglio di progettare prima il tuo database direttamente in SSMS. Dopo che il database è quasi pronto, importarlo in un progetto di database VS 2010. Al termine dell'importazione, è necessario aggiungere sempre nuovi script nel progetto del database per tenere traccia di tutte le modifiche. È possibile utilizzare la funzione di confronto del progetto di database per ottenere tutte le modifiche dal server di sviluppo e importare tutti quegli script direttamente nel progetto. Ora devi solo "eseguire il commit" della modifica nel controller del codice sorgente.

Con questo metodo, puoi avere un database con versione. È possibile individuare la versione di ogni modifica e ripristinare le modifiche.

Questo non è l'unico vantaggio. Con questo tipo di progetto, puoi confrontare qualsiasi database con il tuo progetto per eseguire lo script delle modifiche e con il comando Prompt di SQL PowerShell puoi aggiornare tutti i tuoi database con lo stesso script: questo script è uno schema XML del tuo database. Eseguirà solo i comandi necessari per aggiornare i database. Hai anche la possibilità di effettuare nit test nel tuo database. È disponibile un altro buon articolo per il progetto di database qui . Con la funzione deploy, puoi avere pre-script e post-script. Con quegli script puoi avere la validazione né inserire dati nelle tue tabelle di sistema.

Qui è una buona procedura passo-passo per il progetto di database.

5
Nico

Uso SSMS più di me rispetto a VS2010 perché è lì quando installo SQL Server. Questa è probabilmente la cosa più importante per cui SSMS viene utilizzato più di VS2010, IMHO.

Ho anche scoperto che venditori come Red-Gate stanno mettendo a punto strumenti che si integrano con SSMS e non necessariamente VS2010. Questo può essere positivo in quanto ti consente di migliorare SSMS dove Microsoft non ha. Un esempio di ciò è il controllo del codice sorgente SQL di Red-Gate, che è un componente aggiuntivo di SSMS che consente di connettere SSMS al sistema di controllo del codice sorgente dell'azienda, sia esso Visual Team Foundation o quello che hai. VS2010 ha questo integrato ma rispetto al prezzo dello strumento Reg-Gate ho appena risparmiato un sacco di soldi senza dover acquistare VS2010.

Penso che nel complesso si tratti di preferenze, lavori con ciò in cui ti senti a tuo agio. Se stai addestrando una nuova persona e li alleni su VS2010, questa diventerà la loro preferenza perché sanno come aggirarla.

Se hai iniziato a giocare con SQL Server 2012 potresti aver notato che SSMS sta ottenendo il trucco di VS2010 lentamente ma sicuramente. Quindi alla fine potresti non essere in grado di distinguere tra di loro.

2
user507