• Indledning
• Hvilke muligheder er der, der kan bruges til udviklingsarbejde?
• Hvad ønsker udviklerne?
• Hvor forskellige er udgaverne
• Hvilken indflydelse har valget på de værktøjer, der bruges?
• LocalDB
  • Fordelene ved LocalDb til udvikling
  • Negativerne ved LocalDb til udvikling
• Hvilke andre udgaver findes der?
  • Express Edition
  • Developer Edition
  • Web, Standard, og Enterprise Edition
  • Azure SQL Database
• Containeriseret version af enhver udgave
• Konklusion

Introduktion

Som udvikler har jeg brug for en SQL Server-database, som jeg kan udvikle og teste kode imod. Der er flere muligheder at vælge imellem, og der er forskellige problemer, som du måske skal være opmærksom på. I denne artikel vil vi se på valgmulighederne, og de beslutninger du skal træffe. LocalDb-udgaven af SQL Server blev oprettet for at være den oplagte udgave for udviklere; Giver den idé praktisk mening, og hvilke alternative fordele kommer de andre udgaver for udviklere?

Udviklingsarbejde vil normalt kræve et antal serverinstanser. Skal disse deles på én server, eller skal de fordeles på flere servere eller virtuelle maskiner? Skal alle udviklingsservere være af samme udgave? Er det klogt at stole på en internetforbindelse for at basere alle dine udviklingsservere i skyen, eller er der plads til den traditionelle “SQL Server på den bærbare computer”.

For SQL Server 2005 var det ikke svært at vælge den udgave, som du ville bruge til at udvikle med. Udover selve produktet var der bare en gratis udviklerudgave. Derefter blev det mere kompliceret, og det gør det fortsat, og der kommer nogle interessante permutationer for udviklere med introduktionen af containere til Windows 2016 og SQL Server 2016.

Hvilke muligheder er der, som kan bruges til udviklingsarbejde?

I øjeblikket er der:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure database + Amazon RDS
• Containeriseret version af enhver udgave

Der er også en udgave kaldet Compact Edition, som er blevet forældet, men som stadig er tilgængelig. Den har nogle ligheder med SQL Server, men har et meget lille fodaftryk og kører i en proces. Compact Edition kører en SQL-dialekt, men det er ikke en udgave af SQL Server. Det er virkelig ikke en passende udviklingsinstans til udvikling og test af kode, der skal udrulles til SQL Server.

Hvad ønsker udviklere?

1. Produktivitet
   Jeg er mest produktiv som databaseudvikler, når jeg har min egen instans på min egen maskine, som jeg kan stoppe, starte, droppe og oprette efter forgodtbefindende. Når databasen eller instansen ligger på en delt server, oplever jeg, at udviklingen er langsommere – enten ændrer andre mennesker ting, som jeg arbejder på, eller gør andre ting, der afbryder det, der burde være en hurtig udviklings-, implementerings- og testcyklus.
2. Enkelhed
   En udvikler bør kunne bruge sin tid på at skrive, teste og fejlfinde kode, og al tid, der bruges på at administrere ressourcer som SQL Server-databaser, betyder, at de har mindre tid til at gøre de ting, der rent faktisk er nyttige og giver værdi for virksomheden.
3. Nøjagtighed
   I en ideel verden ville alle udviklere have en hurtig, lokal, nøjagtig kopi af produktionen med data, der er så tæt som muligt på produktionsdata. Med dette kan de teste, at deres ændringer vil opføre sig på samme måde i produktionen, som de gør i deres udviklingsmiljø. Der må være utallige applikationer, der fungerer superhurtigt på en udviklermaskine, men langsommere, når de udrulles i en 3-tier-arkitektur med masser af latenstid og netværksopkald mellem tjenesterne. Det er også vigtigt at verificere, at den kode, man skriver til en database, rent faktisk kan køre på en anden database. Hvis du havde SQL Server 2008 R2 i produktion, ville det ikke give nogen mening at udvikle med SQL 2016 ved hjælp af in-memory-tabeller.

Hvor forskellige er udgaverne?

Når vi udvikler og tester en databaseapplikation, er det ofte vigtigt at vide, at når vi skriver kode, og vi kan se, hvordan den opfører sig i udviklingen, vil vi få en lignende opførsel i produktionen. Udgaverne er defineret af de funktioner, der er installeret og aktiveret; koden i kernemotoren er den samme, uanset om du bruger en af de gratis udgaver eller enterprise-udgaven. Problemet opstår, når du f.eks. bruger en funktion, der kun er til enterprise-versionen, i udvikling, men kun har en instans i standardudgaven i produktion. Den fulde sammenligning af disse udgaver er offentliggjort af Microsoft her ‘Features Supported by the Editions of SQL Server 2016’

Har valget indflydelse på de værktøjer, der bruges?

Alle instanser opfører sig ens med hensyn til kernemotor og sprog; hvis du derfor har et værktøj, der kan administrere Enterprise-udgaven, kan det i princippet også administrere alle andre udgaver. Ikke alle værktøjer har tidligere holdt sig til dette princip: Der var engang en version af SQL Management studio til SQL Express, som var begrænset til ikke at kunne administrere den fulde udgave af funktionerne i den fulde udgave. Nu er SQL Server Management Studio bagudkompatibelt med tidligere versioner og sideløbende kompatibelt med alle udgaver. Det er i øjeblikket tilgængeligt som en gratis download, så du kan administrere enhver instans uden at kræve en fuld licens.

Den anden begrænsning er, at for at kunne bruge LocalDb skal du ændre SQL-klientbiblioteket, og derfor kan ældre versioner af SQLOLEDB og .Net ikke oprette forbindelse – hvis du har en applikation, der er skrevet i .Net, der er tidligere end version 4, så kan den muligvis ikke forbinde.

Hvilket valg af udgaver har vi at udvikle på?

LocalDb

Medmindre du har et specifikt krav, som LocalDb ikke kan opfylde, så må det være første valg for udviklere. Lad os se på, hvad det er, og derefter hvilke fordele det giver.

LocalDb er en nedskåret version af SQL Server, der er specielt designet til at være letvægtig og let at starte og stoppe hurtigt. Det betyder et kompromis, så der er nogle begrænsninger for det, men det er virkelig et godt valg for de fleste udviklere, fordi du hurtigt kan oprette, bruge og ødelægge instanser, der er specifikke for en bestemt bruger.

LocalDb har nogle yderligere fordele: Den deler de samme binære filer for hver instans, så du ikke behøver at bruge masser af diskplads for hver instans, du har brug for. Det betyder, at det er virkelig nemt at starte en op, hvis du finder ud af, at du har brug for en ny instans i varmen af en udviklingssession.

Det er nemt at oprette en ny LocalDb: Du skal blot skrive følgende i kommandoskallen:

Dette vil oprette en ny instans, som du kan bruge, kaldet “instance name”, på min maskine tager det ca. 4 sekunder at oprette en ny instans og derefter ca. yderligere 2 sekunder at starte instansen. Installation af en ny instans af en af de andre typer af SQL Server måles i minutter til timer.

Hvis du har flere versioner af LocalDb installeret, kan du oprette en hvilken som helst af disse versioner rigtig nemt, blot ved at udføre denne kode i en kommandoskærm:

Du vil få en liste som f.eks:

Så hvis du har brug for en 2012-instans, skal du skrive:

Du ville derefter få en ny SQL Server 2012-instans, som du kan oprette forbindelse til.

At oprette forbindelse til LocalDb er en smule anderledes end at oprette forbindelse til en standardinstans: I stedet for at oprette forbindelse til maskinnavnet og enten indtaste en port eller et instansnavn, skal du indtaste ordet “(localdb)” og derefter instansnavnet, så hvis instansen hedder “test-instance”, skal du indtaste dette som dit servernavn:

For at finde ud af, hvilke instanser du har, kan du bruge:

For at finde ud af, hvilke instanser du har, kan du bruge:

Dette vil liste de LocalDb instanser, for at undersøge en yderligere indsæt instansnavnet til den sidste kommando som f.eks:

Opdatet vil være

• navnet
• version
• hvilken bruger den tilhører
• hvorvidt den er startet eller ej
• det sidste starttidspunkt

hvis den er startet, angiver den også stien til den navngivne pipe, den kører på. Hvis du har en klient, der ikke forstår (localdb) servernavnet, så kan du måske forbinde over named pipes til instansen.

LocalDb er fantastisk til at udvikle imod, fordi det er så hurtigt at oprette og starte instanser, hvis du ofte arbejder på forskellige projekter kan du stoppe og starte instanser og have mange forskellige instanser til rådighed uden det overhead at skulle vedligeholde dem og gemme dem på disk. De har naturligvis de samme ulemper som Express, idet de er nedskårne versioner af SQL Server. Der er f.eks. ingen fuldtekstindeksering, hvilket kan forhindre dem i at kunne bruges i nogle applikationer.

Fordelene ved LocalDb til udvikling:

• Snav udvikling, det er nemt at oprette nye instanser til udvikling og test.
• Deler binære filer mellem alle instanser af samme version, så du ikke optager masser af diskplads eller skal vedligeholde mange forskellige versioner

Negativer ved LocalDb til udvikling:

• Indbefatter ikke nogle grundlæggende funktioner som SQL Agent
• Understøtter ikke FILESTREAM
• Kan ikke være en merge replikationsabonnent,
• Kun tillader kun lokale køer for Service Broker.
• kører altid under brugerens sikkerhedskontekst;

Hvilke andre udgaver findes der?

Express Edition

Express Edition er en gratis version af SQL Server, der er beregnet til små databaser med et lavt antal brugere. I 2016-versionen er Express begrænset til fire kerner, 1 GB ram pr. instans og en maksimal databasestørrelse på 10 GB. Selv om det er en rimelig størrelse, er den ikke stor nok til de fleste produktionsdatabaseapplikationer, men den er nyttig til udviklingsarbejde, hvis din udviklingsinstans ikke kræver mange ressourcer og er lille, og hvis du ikke udvikler nogen funktionalitet, der afhænger af Standard- eller Enterprise-only-funktioner..

Fordele ved Express til udvikling:

• Performanceproblemer vil vise sig mere iøjnefaldende under udvikling
• Der er ingen licenskomplikationer ved udviklingsarbejde
• Det er velegnet til både individuel og delt udvikling.
• Netværkstjenester kan konfigureres ligesom med de fulde udgaver, så du kan oprette forbindelse med tcp fra fjernmaskiner og kan bruges af SQL Browser-tjenesten til at tillade forbindelser ved hjælp af instansnavn
• Det kan frit downloades og installeres

Negativer ved Express til udvikling:

• Indbefatter ikke det fulde funktionssæt af en af produktionsversionerne
• Kræver en fuld standardinstallation for at oprette en ny instans, dette tager tid at installere og opgradere og en hel del diskplads pr. instans
• Bør ikke bruges til belastnings- eller præstationstest

Developer Edition

Developer Edition er en fuldt funktionsdygtig Enterprise Edition af SQL Server, som har fjernet alle begrænsninger. Det er godt, hvis du udvikler et program, der bruger Enterprise Edition, men hvis du udvikler et program, der bruger Standard Edition, kan du opleve, at du får en bedre ydeevne end i produktion, eller du ender med at bruge en funktion, der kun er Enterprise Edition. Det kan være en dyr fejl at udvikle kode, for så at opdage, at den ikke kan køres, når du implementerer den.

Hvis du arbejder på en enkelt databaseapplikation og skal implementere til en eksisterende server, der bruger Enterprise-udgaven, så kan du ikke gå meget galt, hvis du bruger udviklingsudgaven af SQL Server.

Licensering af SQL Server 2000 betød, at developer edition var gratis, så længe brugen var til udvikling og test og ikke som produktionsdatabase. Hvis du havde besluttet dig for at bruge developer edition til produktion, ville den have været prissat som enterprise edition. Da SQL 2005 blev frigivet, betød en ændring af licenseringen, at der skulle betales et mindre gebyr på 50 dollars pr. udvikler for at kunne bruge udviklerudgaven. Det betød, at en hel del mennesker ikke kunne bruge udviklingsversionen, især i teams, hvor udviklerne kun sjældent brugte SQL, eller hvor de ikke havde MSDN-abonnementer, som gav udviklerne en licens til udviklerudgaven. Dette var især mærkbart i ikke .net-teams, der tilfældigvis brugte SQL Server.

I henhold til SQL Server 2016-licensvejledningen “SQL Server Developer Edition may not be used in a production environment or with product data” – hvis man antager, at “product data” betyder “produktionsdata”, så ser det ud til, at det ikke er muligt at sikkerhedskopiere og gendanne en produktionsdatabase til at teste mod, medmindre man licenserer serveren som en produktionsserver. I vejledningen står der også, at developer edition kan bruges gratis, hvis du tilmelder dig “Dev Essentials” programmet – hvis du har brug for en anden udgave som Enterprise eller Standard til at udvikle/testes mod, så kan du få adgang til dem ved hjælp af et “Visual Studio” abonnement.

Fordele ved Developer-udgaven til udvikling:

• Developer-udgaven er en fuldt udbygget Enterprise-udgave, så hvis du tester, og det virker på Developer, så bør koden opføre sig på samme måde som din Enterprise-produktions-server.

Negativer ved Developer-udgaven til udvikling:

• Kun egnet til at udvikle en database til Enterprise-udgaven. Da nogle af funktionerne og adfærden i Developer-udgaven mangler i Web- eller Standard-udgaven, vil dit produktionssystem have færre funktioner end dit udviklingsmiljø, hvilket aldrig er en god idé.
• Den bruger ret meget diskplads pr. instans
• Licensering er ikke klar, så det kræver et tjek med din Microsoft-licensrepræsentant

Web-, Standard- og Enterprise-udgaver

Disse versioner kræver alle en licens for at blive brugt i produktion. Du kan kun købe webudgaven gennem udbydere af applikationshosting. Det er ofte sikrest at udvikle mod den udgave af SQL Server, som du vil implementere til, i hvert fald til eventuelle test af ydeevne eller skalerbarhed, hvis ikke til daglig udvikling. Som omtalt i forbindelse med udviklingsudgaven er licenseringen lidt uklar, og du skal muligvis betale for en licens for at bruge en af disse udgaver i et udviklings- eller testmiljø.

Webudgaven er ikke generelt tilgængelig, og du skal normalt købe licenser til den gennem en hostingudbyder, hvilket tilføjer en vis ekstra kompleksitet.

Fordele ved produktionsudgaver til udvikling:

• Du vil udvikle og teste i et miljø, der ligner produktionsmiljøet, hvilket næsten altid er en god ting for udviklere.

Negativer ved produktionsudgaver til udvikling:

• Kræver en fuld standardinstallation for at oprette en ny instans: Det tager tid at installere og opgradere, og det kræver en hel del diskplads pr. instans
• Licensering er ikke klar og kræver kontrol med din Microsoft-licensrepræsentant

Azure SQL Database

Det kan give rigtig god mening at bruge cloud-udbydere til at hoste databaser for dig, når du udvikler og tester, men de har nogle ulemper. Ud over den pris, som du skal betale for at bruge dem, skal du også forstå, at latenstiden mellem din maskine og databasen typisk vil være betydeligt højere end en lokal eller endda LAN-lokal instans. Du skal også have en vedvarende forbindelse til databasen, så det er usandsynligt, at du om aftenen skal afslutte et stykke arbejde i toget.

Det er nok ikke ideelt at bruge dem til rent udviklingsarbejde, hvor du konstant implementerer ændringer og kører scripts, men de kan virkelig komme til sin ret til test, især som en del af automatiserede testsuiter, der kører i hostede udbydere som Appveyor eller VSTS.

At have mulighed for at oprette en ny instans, udrulle din kode og køre dine tests er fantastisk til en kontinuerlig integrationsproces (ci), så du kan køre flere builds samtidig uden at skulle vedligeholde en specifik instans eller database for hvert build – når du går over til at have et enkelt build som en del af din ci-proces, er denne enkle tilgang til udrulning af databaser virkelig en hjælp.

Fordele ved Azure SQL Database til udvikling:

• Enkelhed i forbindelse med opsætning af nye databaser, især da dette kan automatiseres
• Ingen vedligeholdelse af dine udviklingsinstanser, så ingen patching, ingen sikkerhedskopiering osv.

Negativer ved Azure SQL Database til udvikling:

• Mere egnet til test end udvikling, da der kræves en vedvarende forbindelse, og det vil være langsommere end at udvikle lokalt
• Du skal betale pr. minut af databasebrug

Containeriseret version af enhver udgave

Windows 2016 og SQL Server 2016 har begge understøttelse for at køre SQL Server i en container. Th-s giver os al den fleksibilitet, som vi får med LocalDb og Azure+AWS til at starte og stoppe instanser hurtigt. Vi burde også kunne se fordelene ved ikke at skulle patche hver enkelt instans individuelt, så længe vi bruger fælles images til vores instanser.

Windows 2016 er nu blevet frigivet, så vi kan nu potentielt oprette og smide instanser af SQL Server (i hvert fald SQL Server 2016) ret enkelt, hvis vi har Windows 10 eller Windows 2016. Hvis vi er bundet til en tidligere version af Windows eller version af SQL Server, så er det måske ikke så enkelt at oprette et image, der virker.

Når vi får udbredt udbredelse af containere i Windows, bør det betyde, at vi kan oprette nye instanser og starte og stoppe instanser uden den langvarige installationsproces. På nuværende tidspunkt ser det ud til, at det vil være langsommere at starte og stoppe instanser, end det er tilfældet med LocalDb.

Hvis du tester dine databaser i et cloud-lignende miljø som f.eks. Microsoft VSTS-tjenesten, vil du måske også opdage, at det er muligt at starte en LocalDb-instans, da den allerede er installeret. Derimod kan det tage for mange af dine build-minutter at downloade SQL Server 2016-databaseaftrykket og derefter starte det.

Konklusion

Når vi udvikler kode til SQL Server-databaser, har vi som udviklere tre hovedkrav:

• vi skal være produktive så hurtigt som muligt;
• vi ønsker, at vores miljø skal være så simpelt som muligt;
• vi ønsker ikke specielt at være afhængige af gode internetforbindelser;
• vi ønsker at bruge en testversion, der simulerer den virkelige verden ud fra et funktionalitetssynspunkt (ikke nødvendigvis ydeevne til daglig udvikling)

LocalDb er typisk svaret for de fleste SQL Server-udviklere, og medmindre du har et specifikt krav, der betyder, at du ikke kan bruge det, vil jeg varmt anbefale det.