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


42

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?

2
Dalle risposte accumulate finora, sospetto che gli intervistati non stiano utilizzando nessuno degli strumenti del database VS2010 nel modo previsto.
Mark Storey-Smith,

2
@ MarkStorey-Smith - Sì, e la prossima settimana scuoterò tutti con la mia risposta. Da quello che ho imparato e usato finora, VS 2010 è lo strumento per lo sviluppo di database.
Nick Chammas,

In realtà, avevi già progetti di database nelle precedenti versioni di Visual Studio, ma erano disponibili solo nelle edizioni Premium, IIRC.
gonsalu,

1
Le versioni precedenti erano molto diverse.
Mark Storey-Smith,

Uso solo SSMS. SSMS è pienamente in grado di fare ciò che deve essere fatto. Il nostro server non ha bisogno di sapere cosa c'è ...
Asken,

Risposte:


27

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 dello schema di base (ovvero generazione di script differenza / patch) (+ VS2010). Tuttavia non è poi così buono e ha alcuni difetti. Ad esempio, corrisponde ai vincoli sul nome. Se hai una verifica o vincoli predefiniti su una colonna senza nominarli, 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 man mano che i check-in non vengono 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, in modo da poterlo utilizzare 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.

Un'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 fascia 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 - La gestione del progetto e l'integrazione di SC non sono così buone ma funzionano 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 semplificano abbastanza 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.
  • Tracker di problemi open-source - Molti buoni open-source (ad esempio TRAC, Bugzilla per citarne alcuni 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 in modo efficace incertezza, rischio o dipendenze da parti interessate o altre terze parti (vedere 2 sotto).

Pro: migliore modellazione 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: maggiori sforzi per integrare gli strumenti, limitata integrazione dei 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 un set 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, potrebbe 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 project management svolgono 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 spinga 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.


Grazie per aver aggiornato la tua risposta con tutti questi dettagli. È molto più prezioso ora.
Nick Chammas,

2
Non sono d'accordo sul fatto che un file per oggetto sia scomodo. Non è il modo VS2010, è il controllo del codice sorgente 101. Non definisci più classi C # in un singolo file, vero?
Mark Storey-Smith,

2
Onestamente, non lo seguo. Innanzitutto, gli strumenti gestiscono quei file per te, non aggiungendo un sovraccarico alla mia produttività. In secondo luogo, tabelle, chiavi, indici e vincoli sono separati perché a) sono oggetti separati, logicamente e fisicamente b) spesso li manipoli in modo isolato, ad esempio facendo cadere e ricreare gli indici come parte di un refactor che coinvolge il movimento dei dati.
Mark Storey-Smith,

1
Dichiarazioni ampie come "gli strumenti gestiscono i file per te" non sono molto utili, poiché la mia osservazione è che chiaramente non lo fanno - almeno non in modo affidabile. VS2010 potrebbe funzionare correttamente per un singolo utente; non ha funzionato molto bene per una squadra. La mia esperienza è che un partner Gold MS ha avuto difficoltà a gestire un semplice mart di dati contabili con questo. Non erano le persone.
Preoccupato di

2
@ConcernedOfTunbridgeWells, per favore, non vedere i miei commenti come antagonisti o argomentativi in ​​alcun modo, non è mia intenzione. Sono molto interessato a sapere perché VS2010 non viene adottato in modo più ampio, in quanto spesso chiedo ai team di esplorarlo. Se puoi risparmiare tempo per discutere in modo più dettagliato , sarei interessato a sentire i tuoi pensieri.
Mark Storey-Smith,

19

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 fare un cambiamento fondamentale nel 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 OLTP e data warehousing. Non è possibile per me affrontare questo aspetto per ogni aspetto dello sviluppo del database 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 al database di Visual Studio dei 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 di 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 se 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 versione divertenti e richiedono un'ulteriore gestione da parte dell'uomo per ridurre al minimo l'impatto sui tempi di implementazione.

Quindi c'è qualcosa di sbagliato 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 l'aggiornamento 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 sia eseguito manualmente, gli script risultanti sono stati osservati, 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 solo 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 rendere idempotente ogni cambiamento .

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 pensi che @BrentOzar abbia un punto e una delle nuove regole è che tutti sono i 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 infrangere ) 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 cambiamento 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?

  • Non sono perfetti . Ma se sei a conoscenza dei limiti e delle aree problematiche, puoi aggirarli.
  • Movimenti di dati complessi richiedono ancora cura e attenzione ma sono soddisfatti con script pre / post distribuzione.

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 ricche funzionalità IDE di VS2010.
  • VS2010 fornisce un framework per trattare il database come codice.
  • VS2010 porta l' 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.

Kinda risposta utile con alcune avvertenze: 1) Ti sei perso un criterio "Stai sviluppando applicazioni autonome che vengono inviate ai siti client (ovvero: ci sono più copie dello stesso database in circolazione e nuove [vuote] in fase di creazione / venduto tutto il tempo) "2) Hai risposto perché dovremmo considerare un database come codice e gestire i cicli di sviluppo, creazione e distribuzione (che sono già d'accordo). Non vedo un motivo convincente nella tua risposta sul perché dovremmo usare VS2010 come meccanismo per raggiungere questo obiettivo. +2 (risposta premurosa) & -1 (non rispondendo alla domanda reale)
Andrew Bickerton,

2
Di quale "rich IDE" hai bisogno per uno script SQL?
gbn

1
I vantaggi dei cicli di test di build-deploy-automatizzati sono visti a valle. La parte automatizzata di una distribuzione live mi limiterei ad essere "a mani libere", cioè non richiedere passaggi manuali.
Mark Storey-Smith,

1
A parte questo, i tuoi argomenti per l'integrazione hanno qualche merito. Come funziona nel caso generale? Ho avuto problemi con esso, ma oso dire che può essere fatto funzionare.
Preoccupato di

2
@ Nick, lo farò per te :-)
Jack Douglas,

7

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


1
Dovrei essere d'accordo con questo: puoi fare progettazione / sviluppo DB e gestione dello schema con VS2010 ma ci sono catene di strumenti di terze parti che fanno in questo modo, molto meglio.
Preoccupato di

1
Perché dovresti prendere la produzione come copia di riferimento? Penso che sia una cattiva pratica, e probabilmente anche un segno che il tuo controllo del codice sorgente è rotto. Perché il codice del database non dovrebbe appartenere al ciclo di vita dello sviluppo come qualsiasi altra cosa?
Nick Chammas,

@NickChammas: intendo una copia restaurata della produzione. Nel mio negozio attuale, ciò che è nel controllo del codice sorgente non corrisponde al database live. Nel mio ultimo, simile per altre squadre. Ciò che viene distribuito tramite uno script di modifica non è ciò su cui gli sviluppatori stanno lavorando ...
gbn

6

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

Ad essere sincero, il mio voto va direttamente a SQL Server Management Studio per la progettazione, lo sviluppo e (ovviamente) l'amministrazione del database. È più semplice 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 sono uno sviluppatore di software .NET per natura. Ma quando si tratta di progettazione e codifica di database, sceglierò SSMS 11 volte su 10.


In Visual Studio si digita la tabella DDL esattamente allo stesso modo. Stai pensando a qualcos'altro?
Nick Chammas,

1
@Nick Probabilmente ho sbagliato. So che puoi farlo in VS, ma la mia cosa è che è bello avere uno strumento dedicato per quel compito specifico (e di grandi dimensioni) a portata di mano. Sono decisamente una bestia e ho fatto di SSMS la mia abitudine. :)
Thomas Stringer

2
Veramente? Le capacità della soluzione / progetto SSMS sembrano essere state aggiunte da uno stagista 2 settimane prima del lancio.
Mark Storey-Smith,

1
@ MarkStorey-Smith è la domanda allora su come SSMS non disponga davvero del supporto di progetto / soluzione ed è importante per consentire ai team di lavorare bene in un IDE su tutta la linea?
jcolebrand

3
Un esempio sarebbe che SSMS è uno strumento di amministrazione del database, VS2010 è uno strumento di sviluppo del database.
Mark Storey-Smith,

5

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 prompt dei comandi 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 unit test nel tuo database. Un altro buon articolo per il progetto di database è disponibile 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.

Ecco una buona procedura passo-passo per il progetto di database.


4
Non è così che dovrebbe essere fatto lo sviluppo del database in VS2010, sembra che tu abbia perso un po 'il punto. 1) Perché una terra progetterebbe un database greenfield in SSMS e poi importerebbe in VS? 2) Non è necessario "aggiungere sempre nuovi script nel progetto del database" per tenere traccia delle modifiche. 3) Gli script non sono uno "schema xml" del database.
Mark Storey-Smith,

Hai mai provato il progetto di database? 1 - Perché puoi importare il tuo database solo una volta, quindi se non vuoi fare lo script tutto fai il massimo che puoi in SSMS per la prima bozza del database. 2- Hai ragione, puoi monitorare le modifiche con lo strumento di confronto di VS2010 e VS2010 lo genererà per te. 3- Prova il progetto di database, quando distribuirai il tuo progetto di database otterrai uno schema XML del tuo database per aggiornare i tuoi database di produzione.
Nico,

2
Sì, sin dalle prime e più dolorose versioni . Effettivamente importeresti una volta ma ne sincronizzi molti (non che tu debba mai farlo, a meno che non continui a lavorare al di fuori dell'ambiente). Una descrizione più accurata di ciò a cui ti riferisci come script "Schema XML" è che gli strumenti mantengono un meta-modello basato su XML del database, che lo strumento di distribuzione della riga di comando utilizza per creare i comandi necessari per aggiornare un database di destinazione .
Mark Storey-Smith,

2

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.