• Introduktion
• Vilka alternativ finns det som kan användas för utvecklingsarbete?
• Vad vill utvecklare ha?
• Hur olika är utgåvorna
• Influerar valet på de verktyg som används?
• LocalDB
  • Fördelar med LocalDb för utveckling
  • Negativ med LocalDb för utveckling
• Vilka andra utgåvor finns det?
  • Express Edition
  • Developer Edition
  • Web, Standard, och Enterprise Edition
  • Azure SQL Database
• Containeriserad version av alla utgåvor
• Slutsats

Introduktion

Som utvecklare behöver jag en SQL Server-databas som jag kan utveckla och testa kod mot. Det finns flera alternativ att välja mellan, och olika frågor som du kan behöva tänka på. I den här artikeln kommer vi att titta på valen och de beslut du behöver fatta. LocalDb-utgåvan av SQL Server skapades för att vara den självklara utgåvan för utvecklare; är den idén vettig i praktiken och vilka alternativa fördelar kommer de andra utgåvorna för utvecklare?

Utvecklingsarbete kommer vanligtvis att kräva ett antal serverinstanser. Bör dessa delas på en server eller fördelas på ett antal servrar eller virtuella maskiner? Bör alla utvecklingsservrar vara av samma utgåva? Är det klokt att förlita sig på en internetanslutning för att basera alla utvecklingsservrar i molnet, eller finns det en plats för den traditionella “SQL Server on the laptop”.

För SQL Server 2005 var det inte svårt att välja vilken utgåva man skulle använda för att utveckla med. Förutom själva produkten fanns det bara en gratis utvecklarutgåva. Det blev sedan mer komplicerat, och fortsätter att göra det, med några intressanta permutationer som kommer för utvecklare i och med införandet av containrar i Windows 2016 och SQL Server 2016.

Vilka alternativ finns det som skulle kunna användas för utvecklingsarbete?

För närvarande finns det:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure. database + Amazon RDS
• Containerized version of any edition

Det finns också en utgåva som kallas Compact Edition och som inte längre är aktuell men som fortfarande finns tillgänglig. Den har vissa likheter med SQL Server men har ett mycket litet fotavtryck och körs i process. Compact Edition kör en SQL-dialekt, men det är inte en utgåva av SQL Server. Det är verkligen inte en lämplig utvecklingsinstans för att utveckla och testa kod som kommer att distribueras till SQL Server.

Vad vill utvecklare ha?

1. Produktivitet
   Jag är mest produktiv som databasutvecklare när jag har en egen instans på min egen maskin som jag kan stoppa, starta, släppa och skapa när jag vill. När databasen eller instansen finns på en delad server tycker jag att utvecklingen går långsammare – antingen ändrar andra personer saker som jag arbetar med eller gör andra saker för att avbryta det som borde vara en snabb utvecklings-, driftsättnings- och testcykel.
2. Enkelhet
   En utvecklare bör kunna ägna sin tid åt att skriva, testa och felsöka kod, och all tid som går åt till att hantera resurser som SQL Server-databaser innebär att de har mindre tid till att göra de saker som faktiskt är användbara och som ger värde för verksamheten.
3. Noggrannhet
   I en idealisk värld skulle varje utvecklare ha en snabb, lokal, exakt kopia av produktionen med data som är så nära produktionsdata som möjligt. Med detta kan de testa att deras ändringar kommer att bete sig på samma sätt i produktionen som de gör i sin utvecklingsmiljö. Det måste finnas otaliga tillämpningar som fungerar supersnabbt på en utvecklarmaskin men som är långsammare när de används i en arkitektur med tre nivåer med mycket latens och nätverksanrop mellan tjänsterna. Det är också viktigt att kontrollera att den kod du skriver för en databas faktiskt kan köras i en annan databas. Om du hade SQL Server 2008 R2 i produktionen skulle det inte vara någon idé att utveckla med SQL 2016 och använda minnestabeller.

Hur olika är utgåvorna?

När vi utvecklar och testar en databasapplikation är det ofta viktigt att veta att när vi skriver kod och kan se hur den beter sig i utvecklingen, så kommer vi att få ett liknande beteende i produktionen. Editionerna definieras av de funktioner som installeras och aktiveras; koden i kärnmotorn är densamma oavsett om du använder en av gratisutgåvorna eller företagsutgåvan. Problemet uppstår när du använder t.ex. en funktion som endast är avsedd för företag i utvecklingen men endast har en instans i standardutgåvan i produktionen. Den fullständiga jämförelsen av dessa utgåvor publiceras av Microsoft här “Features Supported by the Editions of SQL Server 2016”

Influerar valet på verktygen som används?

Alla instanser beter sig likadant när det gäller kärnmotorn och språket; om du därför har ett verktyg som kan hantera Enterprise edition så kan det i princip också hantera alla andra utgåvor. Det fanns en gång en version av SQL Management Studio för SQL Express som var begränsad till att inte kunna hantera den fullständiga utgåvans funktioner. Nu är SQL Server Management Studio bakåtkompatibel med tidigare versioner och sidokompatibel med alla utgåvor. Den finns för närvarande tillgänglig som en gratis nedladdning så att du kan hantera alla instanser utan att behöva en full licens.

Den andra begränsningen är att för att använda LocalDb måste du ändra SQL-klientbiblioteket och därför kan äldre versioner av SQLOLEDB och .Net inte ansluta – om du har en applikation som är skriven i .Net som är tidigare än version 4 så kanske den inte kan ansluta.

Vilket val av utgåvor har vi att utveckla på?

LocalDb

Om du inte har ett specifikt krav som LocalDb inte kan uppfylla så måste det vara förstahandsvalet för utvecklare. Låt oss titta på vad det är och sedan vilka fördelar det erbjuder.

LocalDb är en nedbantad version av SQL Server som utformades särskilt för att vara lättviktig och lätt att starta och stoppa snabbt. Detta innebär en kompromiss så det finns vissa begränsningar för det, men det är verkligen ett bra val för de flesta utvecklare eftersom du snabbt kan skapa, använda och förstöra instanser som är specifika för en viss användare.

LocalDb har några ytterligare fördelar: Den delar samma binärfiler för varje instans så att du inte behöver använda mycket diskutrymme för varje instans som du behöver. Detta innebär att det är mycket enkelt att starta upp en om du upptäcker att du behöver en ny instans i hettan av en utvecklingssession.

Det är enkelt att skapa en ny LocalDb: Du skriver bara följande i kommandoshällan:

Detta skapar en ny instans som du kan använda och som heter “instance name”, På min maskin tar det cirka 4 sekunder att skapa en ny instans och sedan ytterligare cirka 2 sekunder att starta instansen. Att installera en ny instans av någon av de andra typerna av SQL Server mäts i minuter till timmar.

Om du har flera versioner av LocalDb installerade kan du skapa någon av dessa versioner riktigt enkelt, bara genom att köra den här koden i ett kommandoshell:

Du får en lista som:

Om du behöver en 2012-instans skulle du skriva:

Du får då en ny SQL Server 2012-instans som du kan ansluta till.

Anslutningen till LocalDb är lite annorlunda än anslutningen till en standardinstans: Istället för att ansluta till maskinnamnet och antingen skicka in en port eller ett instansnamn skickar du in ordet “(localdb)” och sedan instansnamnet, så om instansen heter “test-instance” skulle du skicka in detta som ditt servernamn:

För att ta reda på vilka instanser du har kan du använda:

Detta listar LocalDb-instanserna, om du vill undersöka ytterligare en instans så skicka in instansnamnet i det sista kommandot, till exempel:

Utgången blir följande vara

• namnet
• version
• vilken användare den tillhör
• om den startades eller inte
• den senaste starttiden

Om den är startad, anges också sökvägen till det namngivna röret som den körs på. Om du har en klient som inte förstår (localdb)-servernamnet så kanske du kan ansluta över named pipes till instansen.

LocalDb är utmärkt att utveckla mot eftersom det är så snabbt att skapa och starta instanser, om du ofta arbetar med olika projekt kan du stoppa och starta instanser och ha många olika instanser tillgängliga utan att behöva underhålla dem och lagra dem på disk. De har naturligtvis samma nackdelar som Express eftersom de är nedbantade versioner av SQL Server. Det finns till exempel ingen fulltextindexering, vilket kan hindra dem från att kunna användas i vissa tillämpningar.

Fördelar med LocalDb för utveckling:

• Snabb utveckling, det är enkelt att skapa nya instanser för utveckling och testning.
• Delar binärer mellan alla instanser av samma version så att du inte tar upp mycket diskutrymme eller behöver underhålla många olika versioner

Negativ för LocalDb för utveckling:

• Inkluderar inte vissa grundläggande funktioner som SQL Agent
• har inte stöd för FILESTREAM
• kan inte vara en prenumerant för sammanslagningsreplikering,
• tillåter endast lokala köer för Service Broker.
• körs alltid under användarens säkerhetskontext;

Vilka andra utgåvor finns det?

Express Edition

Express Edition är en gratisversion av SQL Server som är avsedd för små databaser med ett lågt antal användare. I 2016 års version är Express begränsad till fyra kärnor, 1 GB ram per instans och en maximal databasstorlek på 10 GB. Även om det är en rimlig storlek är den inte tillräckligt stor för de flesta produktionsdatabastillämpningar, men den är användbar för utvecklingsarbete om din utvecklingsinstans inte kräver många resurser och är liten, och om du inte utvecklar någon funktionalitet som är beroende av Standard- eller Enterprise-only-funktioner..

Fördelar med Express för utveckling:

• Prestationsproblem kommer att visa sig tydligare under utveckling
• Det finns inga licenskomplikationer för utvecklingsarbete
• Det är lämpligt för både enskild och gemensam utveckling.
• Nätverkstjänster kan konfigureras precis som med de fullständiga utgåvorna, så att du kan ansluta med tcp från fjärrmaskiner och kan användas av SQL Browser-tjänsten för att tillåta anslutningar med hjälp av instansnamn
• Det kan laddas ner och installeras fritt

Negativ med Express för utveckling:

• Innehåller inte alla funktioner som en av produktionsversionerna
• Kräver en fullständig standardinstallation för att skapa en ny instans, detta tar tid att installera och uppgradera och ganska mycket diskutrymme per instans
• Bör inte användas för belastnings- eller prestandatester

Developer Edition

Developer edition är en fullt fungerande Enterprise edition av SQL Server där alla begränsningar har tagits bort. Detta är bra om du utvecklar en applikation som använder Enterprise edition, men om du utvecklar en applikation som använder Standard edition kan du upptäcka att du får bättre prestanda än vad du skulle få i produktion eller att du slutar använda en funktion som endast är Enterprise-anpassad. Det kan vara ett kostsamt misstag att utveckla kod för att sedan upptäcka att den inte kan köras när du distribuerar den.

Om du arbetar med en enda databasapplikation och kommer att distribuera till en befintlig server som använder Enterprise-utgåvan kan du inte göra mycket fel om du använder utvecklingsutgåvan av SQL Server.

Licensering för SQL Server 2000 innebar att utvecklarutgåvan var gratis så länge som den användes för utveckling och testning och inte som en produktionsdatabas. Om du hade bestämt dig för att använda utvecklarutgåvan för produktion hade den fått samma pris som företagsutgåvan. När SQL 2005 släpptes innebar en ändring av licensieringen att en liten avgift på 50 dollar per utvecklare skulle tas ut för att få använda utvecklarutgåvan. Detta innebar att en hel del människor inte kunde använda utvecklingsversionen, särskilt i team där utvecklarna endast använde SQL sällan eller där de inte hade MSDN-prenumerationer som försåg utvecklarna med en licens för utvecklarutgåvan. Detta var särskilt märkbart i icke .net-team som råkade använda SQL Server.

Enligt licensguiden för SQL Server 2016 får “SQL Server Developer Edition inte användas i en produktionsmiljö eller med produktdata” – om man utgår från att “produktdata” betyder “produktionsdata” så verkar det som om det inte går att säkerhetskopiera och återställa en produktionsdatabas för att testa mot om man inte licensierar servern som en produktionsserver. I guiden står det också att utvecklarutgåvan kan användas gratis om du ansluter dig till programmet “Dev Essentials” – om du behöver en annan utgåva, t.ex. Enterprise eller Standard, för att utveckla/testa mot dem kan du få tillgång till dem med hjälp av en prenumeration på “Visual Studio”.

Fördelar med Developer edition för utveckling:

• Developer edition är en fullfjädrad Enterprise edition så om du testar och det fungerar på Developer så bör koden bete sig på samma sätt som din produktionsserver för Enterprise.

Negativ med Developer edition för utveckling:

• Endast lämplig för att utveckla en databas för Enterprise Edition. Eftersom en del av funktionerna och beteendet i Developer edition saknas i Web eller Standard Edition kommer ditt produktionssystem att ha färre funktioner än din utvecklingsmiljö, vilket aldrig är en bra idé.
• Den använder ganska mycket diskutrymme per instans
• Licensering är inte klar, så du måste kontrollera med din Microsoft-licensrepresentant

Web-, Standard- och Enterprise-utgåvor

Dessa versioner kräver alla en licens för att kunna användas i produktion. Du kan endast köpa webbutgåvan via leverantörer av programvaruhotell. Det är ofta säkrast att utveckla mot den utgåva av SQL Server som du kommer att distribuera till, säkert för eventuella prestanda- eller skalbarhetstester om än inte för daglig utveckling. Som vi diskuterade med utvecklingsutgåvan är licensieringen lite oklar och du kan eventuellt behöva betala för en licens för att använda en av dessa utgåvor i en utvecklings- eller testmiljö.

Webbutgåvan är inte allmänt tillgänglig och du måste normalt köpa licenser för den via en webbhotellleverantör, vilket ger ytterligare komplexitet.

Fördelar med produktionsutgåvor för utveckling:

• Du kommer att utveckla och testa i en miljö som liknar produktionsmiljön, vilket nästan alltid är bra för utvecklare.

Negativ med produktionsutgåvor för utveckling:

• Kräver en fullständig standardinstallation för att skapa en ny instans: Detta tar tid att installera och uppgradera, och ganska mycket diskutrymme per instans
• Licensering är inte tydlig och kräver att du kontrollerar med din Microsoft-licensrepresentant

Azure SQL Database

Att använda molnleverantörer för att vara värd för databaser åt dig kan vara riktigt vettigt när du utvecklar och testar, men de har vissa nackdelar. Förutom priset som du måste betala för att använda dem måste du också förstå att latensen mellan din maskin och databasen vanligtvis kommer att vara betydligt högre än en lokal eller till och med LAN-lokal instans. Du kommer också att behöva en permanent anslutning till databasen så de där kvällspendlingarna som avslutar ett arbete på tåget är osannolika.

Att använda dessa för rent utvecklingsarbete där du ständigt distribuerar ändringar och kör skript är förmodligen inte idealiskt, men de kan verkligen komma till sin rätt för testning, särskilt som en del av automatiserade testsviter som körs i hostade leverantörer som Appveyor eller VSTS.

Att ha möjlighet att skapa en ny instans, distribuera din kod och köra dina tester är bra för en kontinuerlig integrationsprocess (ci) så att du kan köra flera builds samtidigt utan att behöva underhålla en specifik instans eller databas för varje build – när du väl har gått över till att ha ett enda build som en del av din ci-process är detta enkla tillvägagångssätt för att distribuera databaser verkligen till hjälp.

Fördelar med Azure SQL Database för utveckling:

• Enkelt att konfigurera nya databaser, särskilt eftersom detta kan automatiseras
• Inget underhåll av dina utvecklingsinstanser, så ingen patching, inga säkerhetskopior etc.

Negativ med Azure SQL Database för utveckling:

• Mer lämpad för testning än utveckling eftersom en permanent anslutning krävs och kommer att vara långsammare än att utveckla lokalt
• Du måste betala per minut av databasanvändning

Containeriserad version av valfri utgåva

Windows 2016 och SQL Server 2016 har båda stöd för att köra SQL Server i en container. Th-s ger oss all den flexibilitet som vi får med LocalDb och Azure+AWS för att starta och stoppa instanser snabbt. Vi bör också se fördelarna med att inte behöva patcha varje instans individuellt så länge vi använder gemensamma avbildningar för våra instanser.

Windows 2016 har nu släppts, så vi kan nu potentiellt skapa och slänga instanser av SQL Server (förvisso SQL Server 2016) ganska enkelt om vi har Windows 10 eller Windows 2016. Om vi är bundna till en tidigare version av Windows eller version av SQL Server är det kanske inte lika enkelt att skapa en avbildning som fungerar.

När vi får ett utbrett införande av containrar i Windows bör det innebära att vi kan skapa nya instanser och starta och stoppa instanser utan den långdragna installationsprocessen. I det här skedet verkar det som om det kommer att vara långsammare att starta och stoppa instanser än vad som är fallet med LocalDb.

Om du testar dina databaser i en molnliknande miljö, t.ex. Microsofts VSTS-tjänst, kan du också upptäcka att det är möjligt att starta en LocalDb-instans eftersom den redan är installerad. Att däremot hämta SQL Server 2016-databasavbildningen och sedan starta den kan ta för många av dina byggminuter i anspråk.

Slutsats

När vi utvecklar kod för SQL Server-databaser har vi som utvecklare tre huvudkrav:

• Vi vill vara produktiva så snabbt som möjligt;
• Vi vill att vår miljö ska vara så enkel som möjligt;
• Vi vill inte särskilt förlita oss på god internetuppkoppling;
• Vi vill använda en testversion som simulerar verkligheten ur funktionalitetssynpunkt (inte nödvändigtvis prestanda för daglig utveckling)

LocalDb är typiskt sett svaret för de flesta SQL Server-utvecklare och om du inte har ett specifikt krav som gör att du inte kan använda det, skulle jag starkt rekommendera det.