• Introduzione
• Quali opzioni ci sono che potrebbero essere usate per il lavoro di sviluppo?
• Cosa vogliono gli sviluppatori?
• Quanto sono diverse le edizioni
• La scelta influenza gli strumenti che vengono usati?
• LocalDB
  • Benefici di LocalDb per lo sviluppo
  • Negativi di LocalDb per lo sviluppo
• Quali altre edizioni esistono?
  • Express Edition
  • Developer Edition
  • Web, Standard, e Enterprise Edition
  • Azure SQL Database
• Versione containerizzata di qualsiasi edizione
• Conclusione

Introduzione

Come sviluppatore, ho bisogno di un database SQL Server su cui sviluppare e testare codice. Ci sono diverse opzioni tra cui scegliere, e vari problemi che potresti aver bisogno di tenere a mente. In questo articolo vedremo le scelte e le decisioni da prendere. L’edizione LocalDb di SQL Server è stata creata per essere l’edizione ovvia per gli sviluppatori; questa idea ha un senso pratico e quali vantaggi alternativi hanno le altre edizioni per gli sviluppatori?

Il lavoro di sviluppo di solito richiede un certo numero di istanze del server. Queste dovrebbero essere condivise su un server, o distribuite su un certo numero di server o macchine virtuali? Tutti i server di sviluppo dovrebbero essere della stessa edizione? È saggio fare affidamento su una connessione internet per basare tutti i server di sviluppo nel cloud, o c’è posto per il tradizionale ‘SQL Server sul portatile’.

Prima di SQL Server 2005, non era difficile scegliere l’edizione da usare per sviluppare. Oltre al prodotto stesso, c’era solo un’edizione per sviluppatori gratuita. Poi è diventato più complicato, e continua a farlo, con alcune interessanti permutazioni in arrivo per gli sviluppatori con l’introduzione dei container in Windows 2016 e SQL Server 2016.

Quali opzioni ci sono che potrebbero essere utilizzate per il lavoro di sviluppo?

Al momento c’è:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure database + Amazon RDS
• Versione containerizzata di qualsiasi edizione

C’è anche un’edizione chiamata Compact Edition che è stata deprecata ma è ancora disponibile. Ha alcune somiglianze con SQL Server, ma ha un’impronta molto piccola e viene eseguita in-processo. La Compact Edition esegue un dialetto SQL, ma non è un’edizione di SQL Server. Non è davvero un’istanza di sviluppo appropriata per sviluppare e testare il codice che sarà distribuito su SQL Server.

Cosa vogliono gli sviluppatori?

1. Produttività
   Sono più produttivo come sviluppatore di database quando ho la mia istanza sulla mia macchina che posso fermare, avviare, eliminare e creare a mio piacimento. Quando il database o l’istanza è su un server condiviso allora trovo che lo sviluppo è più lento – o altre persone cambiano cose su cui sto lavorando o fanno altre cose per interrompere, quello che dovrebbe essere, un veloce ciclo di sviluppo, distribuzione e test.
2. Semplicità
   Uno sviluppatore dovrebbe essere libero di passare il suo tempo a scrivere, testare e fare il debug del codice e qualsiasi tempo speso a gestire risorse come i database di SQL Server significa che ha meno tempo per fare le cose che sono effettivamente utili, e fornire valore al business.
3. Precisione
   In un mondo ideale ogni sviluppatore avrebbe una veloce, locale, esatta replica della produzione con dati che sono il più vicino possibile a quelli di produzione. Con questo, possono testare che le loro modifiche si comportino nello stesso modo in produzione come nel loro ambiente di sviluppo. Ci devono essere innumerevoli applicazioni che funzionano super-veloci su una macchina di sviluppo, ma più lente quando vengono distribuite in un’architettura a 3 livelli con molta latenza e chiamate di rete tra i servizi. È anche importante verificare che il codice che si scrive per un database possa effettivamente funzionare su un altro database. Se avete SQL Server 2008 R2 in produzione, non avrebbe senso sviluppare con SQL 2016 usando tabelle in-memory.

Quanto sono diverse le edizioni?

Quando sviluppiamo e testiamo un’applicazione di database, è spesso importante sapere che, quando stiamo scrivendo codice e possiamo vedere come si comporta in sviluppo, otterremo un comportamento simile in produzione. Le edizioni sono definite dalle caratteristiche che sono installate e abilitate; il codice nel motore di base è lo stesso sia che si usi una delle edizioni gratuite o l’edizione enterprise. Il problema arriva quando si usa, per esempio, una caratteristica solo enterprise nello sviluppo ma si ha solo un’istanza dell’edizione standard in produzione. Il confronto completo di queste edizioni è pubblicato da Microsoft qui ‘Features Supported by the Editions of SQL Server 2016’

La scelta influenza gli strumenti che vengono utilizzati?

Tutte le istanze si comportano allo stesso modo in termini di motore e linguaggio di base; se, quindi, avete uno strumento che può gestire l’edizione Enterprise allora può, in linea di principio, anche gestire ogni altra edizione. Non tutti gli strumenti in passato si attenevano a questo principio: una volta c’era una versione di SQL Management Studio per SQL Express che era limitata a non poter gestire le funzionalità dell’edizione completa. Ora SQL Server Management Studio è compatibile all’indietro con le versioni precedenti e lateralmente con tutte le edizioni. Attualmente è disponibile come download gratuito in modo da poter gestire qualsiasi istanza senza richiedere una licenza completa.

La seconda limitazione è che, al fine di utilizzare LocalDb, è necessario modificare la libreria client SQL e quindi le vecchie versioni di SQLOLEDB e .Net non sono in grado di connettersi – se avete un’applicazione che è stata scritta in .net che è precedente alla versione 4 allora potrebbe non connettersi.

Quale scelta di edizioni abbiamo per sviluppare?

LocalDb

A meno che tu non abbia un requisito specifico che LocalDb non può soddisfare, allora deve essere la prima scelta per gli sviluppatori. Vediamo cos’è e quali vantaggi offre.

LocalDb è una versione ridotta di SQL Server che è stata specificamente progettata per essere leggera e facile da avviare e fermare rapidamente. Questo significa un compromesso, quindi ci sono alcune restrizioni per esso, ma è davvero una grande scelta per la maggior parte degli sviluppatori perché è possibile creare, utilizzare e distruggere rapidamente le istanze che sono specifiche per un particolare utente.

LocalDb ha alcuni vantaggi aggiuntivi: Condivide gli stessi binari per ogni istanza in modo da non dover utilizzare molto spazio su disco per ogni istanza di cui avete bisogno. Questo significa che è molto semplice avviarne una se si scopre che si ha bisogno di una nuova istanza nel bel mezzo di una sessione di sviluppo.

Creare un nuovo LocalDb è semplice: Basta digitare quanto segue nella shell di comando:

Questo creerà una nuova istanza che puoi usare chiamata “instance name”, sulla mia macchina ci vogliono circa 4 secondi per creare una nuova istanza e poi circa altri 2 secondi per avviarla. L’installazione di una nuova istanza di qualsiasi altro tipo di SQL Server si misura in minuti o ore.

Se avete più versioni di LocalDb installate, potete creare una qualsiasi di queste versioni molto facilmente, semplicemente eseguendo questo codice in una shell di comando:

Avrai una lista come:

Quindi se avete bisogno di un’istanza 2012 dovreste digitare:

Allora si otterrebbe una nuova istanza di SQL Server 2012 a cui ci si può connettere.

Connettersi a LocalDb è un po’ diverso dal connettersi a un’istanza standard: Invece di connettersi al nome della macchina e passare una porta o il nome dell’istanza, si passa la parola “(localdb)” e poi il nome dell’istanza, quindi se l’istanza si chiama “test-instance” si passa questo come nome del server:

Per scoprire quali istanze avete potete usare:

Questo elencherà le istanze di LocalDb, per esaminarne una ulteriore passare il nome dell’istanza all’ultimo comando come:

L’output sarà sarà

• il nome
• la versione
• a quale utente appartiene
• se è stata avviata o meno
• l’ultima ora di avvio

Se è avviata, fornisce anche il percorso della pipe nominata su cui è in esecuzione. Se avete un client che non capisce il nome del server (localdb) allora forse potete connettervi all’istanza tramite named pipe.

LocalDb è ottimo per lo sviluppo perché è così veloce da creare e avviare le istanze, se lavorate spesso su progetti diversi potete fermare e avviare le istanze e avere molte istanze diverse disponibili senza l’overhead di doverle mantenere e memorizzare su disco. Ovviamente hanno gli stessi lati negativi di Express nel senso che sono versioni ridotte di SQL Server. Non c’è, per esempio, l’indicizzazione del testo completo, che può impedirne l’uso in alcune applicazioni.

Benefici di LocalDb per lo sviluppo:

• Sviluppo veloce, è semplice creare nuove istanze per lo sviluppo e i test.
• Condivide i binari tra tutte le istanze della stessa versione in modo da non occupare molto spazio su disco o dover mantenere molte versioni diverse

Negativi di LocalDb per lo sviluppo:

• Non include alcune caratteristiche fondamentali come SQL Agent
• non supporta FILESTREAM
• non può essere un sottoscrittore di replica merge,
• consente solo code locali per Service Broker.
• Viene sempre eseguito sotto il contesto di sicurezza dell’utente;

Quali altre edizioni ci sono?

Express Edition

L’edizione Express è una versione gratuita di SQL Server che è destinata a piccoli database con un basso numero di utenti. Nella versione 2016 Express è limitata a quattro core, 1GB di ram per istanza e una dimensione massima del database di 10 GB. Anche se è una dimensione ragionevole non è abbastanza grande per la maggior parte delle applicazioni di database di produzione, ma è utile per il lavoro di sviluppo se la vostra istanza di sviluppo non richiede molte risorse ed è piccola, e se non state sviluppando alcuna funzionalità che dipende dalle caratteristiche Standard o Enterprise-only.

Benefici di Express per lo sviluppo:

• I problemi di performance si manifesteranno più vistosamente nello sviluppo
• Non ci sono complicazioni di licenza per il lavoro di sviluppo
• È adatto sia allo sviluppo individuale che condiviso.
• I servizi di rete possono essere configurati come con le edizioni complete, quindi è possibile connettersi con tcp da macchine remote e può essere usato dal servizio SQL Browser per permettere connessioni usando il nome dell’istanza
• Può essere liberamente scaricato e installato

Negativi di Express per lo sviluppo:

• Non include il set completo di funzionalità di una delle versioni di produzione
• Richiede un’installazione standard completa per creare una nuova istanza, questo richiede tempo per l’installazione e l’aggiornamento e un sacco di spazio su disco per istanza
• Non dovrebbe essere usato per test di carico o prestazioni

Developer Edition

Developer edition è una edizione Enterprise completamente funzionale di SQL Server che ha tutte le limitazioni rimosse. Questo è ottimo se stai sviluppando un’applicazione che usa l’edizione Enterprise, ma se stai sviluppando un’applicazione che usa l’edizione Standard allora potresti scoprire che ottieni prestazioni migliori di quelle che avresti in produzione o finisci per usare una caratteristica che è solo enterprise. Può essere un errore costoso sviluppare del codice, solo per scoprire che non può essere eseguito quando lo si distribuisce.

Se si lavora su una singola applicazione di database e si distribuisce su un server esistente che usa l’edizione Enterprise, allora non si può sbagliare di molto se si usa l’edizione di sviluppo di SQL Server.

Le licenze di SQL Server 2000 significavano che l’edizione per sviluppatori era gratuita finché l’uso era per sviluppo e test piuttosto che come database di produzione. Se si fosse deciso di usare l’edizione per sviluppatori per la produzione, allora sarebbe stata valutata come l’edizione enterprise. Quando fu rilasciato SQL 2005, un cambiamento nelle licenze significò che c’era una piccola tassa di 50 dollari per sviluppatore per poter usare l’edizione per sviluppatori. Questo significava che molte persone non erano in grado di usare la versione di sviluppo, specialmente nei team dove gli sviluppatori usavano SQL solo raramente o dove non avevano abbonamenti MSDN che fornivano agli sviluppatori una licenza per l’edizione per sviluppatori. Questo era particolarmente evidente nei team non .net che usavano SQL Server.

Secondo la guida alle licenze di SQL Server 2016, “SQL Server Developer Edition non può essere utilizzato in un ambiente di produzione o con dati di prodotto” – assumendo che “dati di prodotto” significa “dati di produzione”, allora sembra che non sia possibile eseguire il backup e il ripristino di un database di produzione per il test a meno che non si conceda la licenza del server come server di produzione. La guida afferma anche che l’edizione per sviluppatori può essere utilizzata gratuitamente se si aderisce al programma “Dev Essentials” – se si ha bisogno di un’edizione diversa come Enterprise o Standard per sviluppare/testare, allora è possibile accedervi utilizzando un abbonamento “Visual Studio”.

Benefici dell’edizione Developer per lo sviluppo:

• L’edizione Developer è un’edizione Enterprise a tutti gli effetti, quindi se stai testando e funziona su Developer allora il codice dovrebbe comportarsi come il tuo server Enterprise di produzione.

Negativi dell’edizione Developer per lo sviluppo:

• Solo appropriato per sviluppare un database per Enterprise Edition. Poiché alcune delle caratteristiche e dei comportamenti dell’edizione Developer mancano nell’edizione Web o Standard, il vostro sistema di produzione avrà meno caratteristiche del vostro ambiente di sviluppo, il che non è mai una buona idea.
• Utilizza parecchio spazio su disco per istanza
• Le licenze non sono chiare, quindi richiede un controllo con il rappresentante delle licenze Microsoft

Edizione web, Standard ed Enterprise

Queste versioni richiedono tutte una licenza per essere usate in produzione. È possibile acquistare l’edizione web solo attraverso i fornitori di hosting di applicazioni. È spesso più sicuro sviluppare con l’edizione di SQL Server che si distribuirà, certamente per qualsiasi test di performance o scalabilità, se non per lo sviluppo quotidiano. Come discusso con l’edizione di sviluppo, le licenze sono un po’ poco chiare e potreste potenzialmente dover pagare una licenza per usare una di queste edizioni in un ambiente di sviluppo o di test.

L’edizione web non è generalmente disponibile e normalmente dovete comprare le licenze per essa attraverso un fornitore di hosting che aggiunge una certa complessità.

Benefici delle edizioni di produzione per lo sviluppo:

• Si sviluppano e si testano in un ambiente simile a quello di produzione, che è quasi sempre una buona cosa per gli sviluppatori.

Negativi delle edizioni di produzione per lo sviluppo:

• Richiede una installazione standard completa per creare una nuova istanza: Questo richiede tempo per l’installazione e l’aggiornamento, e un bel po’ di spazio su disco per istanza
• Le licenze non sono chiare e richiedono un controllo con il rappresentante delle licenze Microsoft

Azure SQL Database

Utilizzare i provider cloud per ospitare i database per voi può avere davvero senso quando si sviluppa e si testa, ma hanno alcuni lati negativi. A parte il prezzo che dovete pagare per usarli, dovete anche capire che la latenza tra la vostra macchina e il database sarà tipicamente molto più alta di un’istanza locale o anche LAN. Avrete anche bisogno di una connessione persistente al database, quindi quei pendolari serali che finiscono un pezzo di lavoro sul treno sono improbabili.

Utilizzare questi per il lavoro di sviluppo puro dove si stanno costantemente distribuendo le modifiche e l’esecuzione di script non è probabilmente l’ideale, ma possono davvero venire in proprio per i test, soprattutto come parte di suite di test automatizzati che vengono eseguiti in provider ospitati come Appveyor o VSTS.

Avere la possibilità di creare una nuova istanza, distribuire il codice ed eseguire i test è ottimo per un processo di integrazione continua (ci) in modo da poter eseguire più build contemporaneamente senza dover mantenere un’istanza o un database specifico per ogni build – una volta che si passa ad avere una singola build come parte del processo ci questo semplice approccio al deploy dei database aiuta davvero.

Benefici di Azure SQL Database per lo sviluppo:

• Semplicità nell’impostazione di nuovi database, soprattutto perché questo può essere automatizzato
• Nessuna manutenzione delle istanze di sviluppo quindi nessuna patch, nessun backup ecc.

Negativi di Azure SQL Database per lo sviluppo:

• Più adatto ai test che allo sviluppo in quanto è richiesta una connessione persistente e sarà più lento che sviluppare localmente
• Devi pagare per minuto di utilizzo del database

Versione containerizzata di qualsiasi edizione

Windows 2016 e SQL Server 2016 hanno entrambi il supporto per eseguire SQL Server in un contenitore. Questo ci dà tutta la flessibilità che abbiamo con LocalDb e Azure+AWS per avviare e fermare le istanze rapidamente. Dovremmo anche vedere i vantaggi di non aver bisogno di patchare ogni istanza individualmente, finché usiamo immagini comuni per le nostre istanze.

Windows 2016 è stato rilasciato, quindi ora possiamo potenzialmente creare e buttare via istanze di SQL Server (certamente SQL Server 2016) abbastanza semplicemente se abbiamo Windows 10 o Windows 2016. Se siamo legati a una versione precedente di Windows o a una versione di SQL Server, allora potrebbe non essere così semplice creare un’immagine che funzioni.

Una volta che avremo un’adozione diffusa dei contenitori in Windows, dovrebbe significare che possiamo creare nuove istanze e avviare e fermare le istanze senza il lungo processo di installazione. In questa fase, sembra che sarà più lento avviare e fermare le istanze rispetto a LocalDb.

Se testate i vostri database in un ambiente simile al cloud come il servizio VSTS di Microsoft, potreste anche scoprire che avviare un’istanza di LocalDb è fattibile in quanto è già installato. Al contrario, scaricare l’immagine del database di SQL Server 2016 e poi avviarlo potrebbe occupare troppi minuti di compilazione.

Conclusione

Quando si sviluppa codice per i database di SQL Server noi, come sviluppatori, abbiamo tre requisiti principali:

• dobbiamo essere produttivi il più velocemente possibile;
• vogliamo che il nostro ambiente sia il più semplice possibile;
• non vogliamo particolarmente fare affidamento su una buona connettività internet;
• Vogliamo usare una versione di test che simuli il mondo reale da un punto di vista funzionale (non necessariamente le prestazioni per lo sviluppo quotidiano)

LocalDb è tipicamente la risposta per la maggior parte degli sviluppatori di SQL Server e, a meno che tu non abbia un requisito specifico che ti impedisce di usarlo, lo consiglio vivamente.