• Esittely
• Mitkä vaihtoehdot soveltuvat kehitystyöhön?
• Mitä kehittäjät haluavat?
• Miten eri versiot eroavat toisistaan
• Vaikuttaako valinta käytettäviin työkaluihin?
• LocalDB
  • Hyötyjä LocalDb:stä kehitystyössä
  • Hyötyjä LocalDb:stä kehitystyössä
• Mitä muita painoksia on olemassa?
  • Express Edition
  • Developer Edition
  • Web, Standard, and Enterprise Editions
  • Azure SQL Database
• Containerized version of any edition
• Conclusion

Introduction

Kehittäjänä tarvitsen SQL Server -tietokannan, jota vasten voin kehittää ja testata koodia. Valittavana on useita vaihtoehtoja ja erilaisia seikkoja, jotka kannattaa ottaa huomioon. Tässä artikkelissa tarkastelemme vaihtoehtoja ja päätöksiä, jotka sinun on tehtävä. SQL Serverin LocalDb-versio luotiin itsestään selväksi versioksi kehittäjille; Onko tämä ajatus käytännöllisesti katsoen järkevä ja mitä vaihtoehtoisia etuja muut versiot tarjoavat kehittäjille?

Kehitystyössä tarvitaan yleensä useita palvelininstansseja. Pitäisikö nämä jakaa yhdelle palvelimelle vai hajauttaa useille palvelimille tai virtuaalikoneille? Pitäisikö kaikkien kehityspalvelimien olla samaa versiota? Onko järkevää luottaa internet-yhteyteen, jotta kaikki kehityspalvelimet voidaan sijoittaa pilvipalvelimiin, vai onko perinteiselle “kannettavalla tietokoneella olevalle SQL-palvelimelle” tilaa.

Ennen SQL Server 2005:tä ei ollut vaikeaa valita, millä versiolla kehität. Muuta kuin itse tuote, oli vain ilmainen developer edition. Sen jälkeen asia monimutkaistui ja monimutkaistuu edelleen, ja kehittäjille on tulossa mielenkiintoisia permutaatioita, kun Windows 2016:ssa ja SQL Server 2016:ssa otetaan käyttöön kontit.

Mitä vaihtoehtoja on olemassa, joita voisi käyttää kehitystyöhön?

Tällä hetkellä on:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure. tietokanta + Amazon RDS
• Containerized versio mistä tahansa versiosta

On olemassa myös versio nimeltä Compact Edition, joka on poistunut käytöstä, mutta on edelleen saatavilla. Sillä on joitakin yhtäläisyyksiä SQL Serverin kanssa, mutta se on hyvin pienikokoinen ja toimii prosessin sisällä. Compact Edition käyttää SQL-murretta, mutta se ei ole SQL Serverin versio. Se ei todellakaan ole sopiva kehitysinstanssi SQL Serveriin käyttöönotettavan koodin kehittämiseen ja testaamiseen.

Mitä kehittäjät haluavat?

1. Tuottavuus
   Tietokannan kehittäjänä olen tuottavin silloin, kun minulla on oma instanssi omalla koneellani, jonka voin pysäyttää, käynnistää, pudottaa ja luoda mieleni mukaan. Kun tietokanta tai instanssi on jaetulla palvelimella, huomaan, että kehitys on hitaampaa – joko muut ihmiset muuttavat asioita, joiden parissa työskentelen, tai tekevät muita asioita, jotka keskeyttävät sen, minkä pitäisi olla nopea kehitys-, käyttöönotto- ja testaussykli.
2. Yksinkertaisuus
   Kehittäjän pitäisi voida käyttää aikaansa koodin kirjoittamiseen, testaamiseen ja virheenkorjaukseen, ja SQL Server -tietokantojen kaltaisten resurssien hallintaan kuluva aika tarkoittaa, että kehittäjällä on vähemmän aikaa tehdä asioita, jotka ovat oikeasti hyödyllisiä ja tuottavat arvoa liiketoiminnalle.
3. Tarkkuus
   Ideaalimaailmassa jokaisella kehittäjällä olisi käytössään nopea, paikallinen, tarkka jäljennös tuotantotiedostosta, ja sen sisältämät datat vastaisivat tuotantotietoja mahdollisimman hyvin. Tämän avulla he voivat testata, että heidän tekemänsä muutokset käyttäytyvät tuotannossa samalla tavalla kuin kehitysympäristössä. On varmasti lukemattomia sovelluksia, jotka toimivat supernopeasti kehittäjäkoneella mutta hitaammin, kun ne otetaan käyttöön kolmiportaisessa arkkitehtuurissa, jossa on paljon latenssia ja verkkokutsuja palveluiden välillä. On myös tärkeää varmistaa, että yhtä tietokantaa varten kirjoitettu koodi todella toimii toisessa tietokannassa. Jos sinulla olisi SQL Server 2008 R2 tuotannossa, ei olisi mitään järkeä kehittää SQL 2016:lla käyttäen muistissa olevia taulukoita.

Miten eri versiot eroavat toisistaan?

Tietokantasovellusta kehitettäessä ja testattaessa on usein tärkeää tietää, että kun kirjoitamme koodia ja näemme, miten se toimii kehityksessä, saamme samanlaisen käyttäytymisen tuotannossa. Editiot määritellään asennettujen ja käyttöön otettujen ominaisuuksien perusteella; ydinmoottorin koodi on sama riippumatta siitä, käytätkö jotakin ilmaisversiota vai enterprise-versiota. Ongelma syntyy, kun kehitystyössä käytetään esimerkiksi vain yrityskäyttöön tarkoitettua ominaisuutta, mutta tuotannossa on vain Standard-edition-versio. Microsoft on julkaissut näiden versioiden täydellisen vertailun täällä ‘Features Supported by the Editions of SQL Server 2016’

Vaikuttaako valinta käytettäviin työkaluihin?

Kaikki instanssit käyttäytyvät samalla tavalla ydinmoottorin ja kielen suhteen; jos sinulla on siis työkalu, joka pystyy hallitsemaan Enterprise-versiota, se pystyy periaatteessa hallitsemaan myös kaikkia muita versioita. Aiemmin kaikki työkalut eivät ole noudattaneet tätä periaatetta: SQL Management Studiosta oli aikoinaan SQL Express -versio, joka oli rajoitettu siten, että se ei pystynyt hallitsemaan täyden painoksen ominaisuuksia. Nyt SQL Server Management Studio on taaksepäin yhteensopiva aiempiin versioihin ja sivuttain yhteensopiva kaikkien versioiden kanssa. Se on tällä hetkellä ladattavissa ilmaiseksi, joten voit hallita mitä tahansa instanssia tarvitsematta täyttä lisenssiä.

Toinen rajoitus on se, että LocalDb:n käyttäminen edellyttää SQL-asiakaskirjaston muuttamista, joten SQLOLEDB:n ja .Netin vanhemmat versiot eivät pysty muodostamaan yhteyttä – jos sinulla on sovellus, joka on kirjoitettu .Net, joka on aikaisempi kuin versio 4, niin se ei välttämättä muodosta yhteyttä.

Mitä versioita voimme valita kehitettäväksi?

LocalDb

Jos sinulla ei ole erityistä vaatimusta, jota LocalDb ei pysty täyttämään, niin sen on oltava kehittäjien ensimmäinen valinta. Katsotaan, mikä se on ja mitä etuja se tarjoaa.

LocalDb on karsittu versio SQL Serveristä, joka on suunniteltu erityisesti kevyeksi ja helposti käynnistettäväksi ja pysäytettäväksi nopeasti. Tämä tarkoittaa kompromissia, joten siihen liittyy joitakin rajoituksia, mutta se on todella hyvä valinta useimmille kehittäjille, koska voit nopeasti luoda, käyttää ja tuhota vain yhdelle tietylle käyttäjälle tarkoitettuja instansseja.

LocalDb:llä on joitakin lisäetuja: Se jakaa samat binäärit jokaiselle instanssille, joten sinun ei tarvitse käyttää paljon levytilaa jokaista tarvitsemaasi instanssia varten. Tämä tarkoittaa, että on todella helppoa käynnistää yksi, jos huomaat tarvitsevasi uuden instanssin kehityssession kuumuudessa.

Uuden LocalDb:n luominen on yksinkertaista: Kirjoitat vain komentotulkkiin seuraavan komennon:

Tällöin luodaan uusi instanssi, jota voit käyttää nimellä “instanssin nimi”, minun koneellani uuden instanssin luominen kestää noin 4 sekuntia ja sitten vielä noin 2 sekuntia instanssin käynnistäminen. Minkä tahansa muun tyyppisen SQL Serverin uuden instanssin asentaminen mitataan minuuteista tunteihin.

Jos sinulla on asennettuna useita versioita LocalDb:stä, voit luoda minkä tahansa näistä versioista todella helposti suorittamalla tämän koodin komentotulkissa:

Saat seuraavanlaisen luettelon:

Jos sitten tarvitset vuoden 2012 instanssin, kirjoitat:

Tällöin saisit uuden SQL Server 2012 -instanssin, johon voisit muodostaa yhteyden.

Yhteyden muodostaminen LocalDb:hen eroaa hieman tavallisesta instanssista: Sen sijaan, että ottaisit yhteyden koneen nimeen ja antaisit joko portin tai instanssin nimen, annat sanan “(localdb)” ja sitten instanssin nimen, joten jos instanssin nimi on “test-instance”, antaisit tämän palvelimen nimeksi:

Tietääksesi, mitä instansseja käytössäsi on, voit käyttää seuraavaa:

Tämä listaa LocalDb:n instanssit, tutkiaksesi yhtä tarkemmin syötä instanssin nimi viimeiseen komentoon esim:

Tulosteeksi tulee on

• nimi
• versio
• mille käyttäjälle se kuuluu
• onko se käynnistetty vai ei
• viimeinen käynnistysaika

Jos se on käynnistetty, se antaa myös sen nimetyn putken polun, jossa se on käynnissä. Jos sinulla on asiakas, joka ei ymmärrä (localdb)palvelinnimeä, niin ehkä voit muodostaa nimettyjen putkien kautta yhteyden instanssiin.

LocalDb on loistava kehitettäessä sitä vastaan, koska instanssien luominen ja käynnistäminen on niin nopeaa, jos työskentelet usein eri projektien parissa, voit pysäyttää ja käynnistää instansseja ja sinulla voi olla paljon erilaisia instansseja käytettävissä ilman, että niiden ylläpito ja tallentaminen levylle aiheuttaa ylimääräisiä kustannuksia. Niillä on tietenkin samat huonot puolensa kuin Expressillä, sillä ne ovat SQL Serverin pelkistettyjä versioita. Niissä ei esimerkiksi ole kokoteksti-indeksointia, mikä voi estää niiden käytön joissakin sovelluksissa.

LocalDb:n edut kehitystyössä:

• Nopea kehitys, uusien instanssien luominen kehitystyötä ja testausta varten on helppoa.
• Jaa binäärit kaikkien saman version instanssien kesken, joten et vie paljon levytilaa tai joudu ylläpitämään monia eri versioita

Negatiiviset puolet LocalDb:stä kehitystä varten:

• Ei sisällä joitakin perusominaisuuksia, kuten SQL Agent
• ei tue FILESTREAMia
• ei voi olla merge-replikoinnin tilaaja,
• sallii vain paikalliset jonot Service Brokerille.
• suoritetaan aina käyttäjän suojauskontekstissa;

Mitä muita versioita on olemassa?

Express Edition

Express Edition on ilmainen versio SQL Serveristä, joka on tarkoitettu pienille tietokannoille, joissa on vähän käyttäjiä. Vuoden 2016 versiossa Express on rajoitettu neljään ytimeen, 1 Gt RAM-muistiin instanssia kohden ja tietokannan maksimikoko on 10 Gt. Vaikka koko on kohtuullinen, se ei ole riittävän suuri useimpiin tuotantotietokantasovelluksiin, mutta se on hyödyllinen kehitystyössä, jos kehitysinstanssisi ei vaadi paljon resursseja ja on pieni ja jos et kehitä toimintoja, jotka ovat riippuvaisia Standard- tai Enterprise-only-ominaisuuksista..

Expressin edut kehitystyössä:

• Suorituskykyongelmat näkyvät selvemmin kehitystyössä
• Kehitystyössä ei ole lisenssikomplikaatioita
• Se soveltuu sekä yksilölliseen että yhteiseen kehitystyöhön.
• Verkkopalvelut voidaan konfiguroida kuten täysissä versioissa, joten voit muodostaa yhteyden tcp:llä etäkoneista ja SQL Browser -palvelu voi sallia yhteydet instanssinimen avulla
• Sen voi vapaasti ladata ja asentaa

Expressin negatiiviset puolet kehitystyössä:

• Ei sisällä yhden tuotantoversion täyttä ominaisuusvalikoimaa
• Tarvitsee täyden vakioasennuksen uuden instanssin luomiseksi, tämä vie aikaa asennukseen ja päivitykseen ja melko paljon levytilaa instanssia kohden
• Ei pidä käyttää kuormitus- tai suorituskykytestaukseen

Kehittäjäversio

Kehittäjäversio on täysipainoinen Enterprise-julkaisu SQL Serveristä, josta on poistettu kaikki rajoitukset. Tämä on hienoa, jos kehität sovellusta, joka käyttää Enterprise-versiota, mutta jos kehität sovellusta, joka käyttää Standard-versiota, saatat huomata, että saat paremman suorituskyvyn kuin tuotannossa tai päädyt käyttämään ominaisuutta, joka on vain Enterprise-versio. Voi olla kallis virhe kehittää koodia ja huomata, että sitä ei voi ajaa, kun se otetaan käyttöön.

Jos työskentelet yksittäisen tietokantasovelluksen parissa ja otat sen käyttöön olemassa olevalle palvelimelle, joka käyttää Enterprise-versiota, et voi mennä pahasti pieleen, jos käytät SQL Serverin kehitysversiota.

SQL Server 2000:n lisensointi tarkoitti sitä, että kehittäjäversio oli maksuton, kunhan sitä käytettiin kehitykseen ja testaukseen eikä tuotantotietokantaan. Jos olisit päättänyt käyttää developer editionia tuotantoon, sen hinta olisi ollut sama kuin enterprise editionin. Kun SQL 2005 julkaistiin, lisensoinnin muutos merkitsi sitä, että kehittäjäpainoksen käytöstä perittiin pieni 50 dollarin maksu kehittäjää kohti. Tämä tarkoitti sitä, että monet ihmiset eivät voineet käyttää kehitysversiota etenkään sellaisissa tiimeissä, joissa kehittäjät käyttivät SQL:ää vain harvoin tai joissa heillä ei ollut MSDN-tilausta, joka toimitti kehittäjille lisenssin kehitysversiota varten. Tämä näkyi erityisesti muissa kuin .net-tiimeissä, jotka sattuivat käyttämään SQL Serveriä.

SQL Server 2016 -lisensointioppaan mukaan “SQL Server Developer Editionia ei saa käyttää tuotantoympäristössä tai tuotetietojen kanssa” – olettaen, että “tuotetiedoilla” tarkoitetaan tuotantotietoja, näyttää siltä, että tuotantotietokannan varmuuskopioiminen ja palauttaminen testausta varten ei ole mahdollista, ellei palvelinta lisensoida tuotantopalvelimeksi. Oppaassa todetaan myös, että kehittäjäversiota voi käyttää ilmaiseksi, jos liityt “Dev Essentials” -ohjelmaan – jos tarvitset eri versiota, kuten Enterprise- tai Standard-versiota, jota vastaan voit kehittää tai testata, voit käyttää niitä “Visual Studio” -tilauksen avulla.

Kehittäjäpainoksen edut kehitykseen:

• Kehittäjäpainos on täysimittainen Enterprise-painos, joten jos testaat ja se toimii Developer-palvelimella, niin koodin pitäisi käyttäytyä samalla tavalla kuin tuotantopalvelimen Enterprise-palvelimella.

Kehittäjäpainoksen negatiiviset puolet kehitykseen:

• Käytetään vain tietokannan kehittelyyn Enterpriselle. Koska osa Developer editionin ominaisuuksista ja käyttäytymisestä puuttuu Web- tai Standard Editionista, tuotantojärjestelmässäsi on vähemmän ominaisuuksia kuin kehitysympäristössäsi, mikä ei ole koskaan hyvä idea.
• Se käyttää melko paljon levytilaa instanssia kohden
• Lisensointi ei ole selkeä, joten se vaatii tarkistuksen Microsoftin lisenssiedustajalta

Web-, Standard- ja Enterprise-versiot

Nämä versiot vaativat kaikki lisenssin, jotta niitä voidaan käyttää tuotannossa. Web-versiota voi ostaa vain sovellushosting-palveluntarjoajien kautta. Usein on turvallisinta kehittää sitä SQL Server -versiota vastaan, jota käytetään, ainakin suorituskyky- tai skaalautuvuustestien yhteydessä, jos ei jokapäiväisessä kehitystyössä. Kuten kehitysversiosta puhuttiin, lisensointi on hieman epäselvää, ja saatat joutua mahdollisesti maksamaan lisenssistä, jos haluat käyttää jotakin näistä versioista kehitys- tai testiympäristössä.

Web-versio ei ole yleisesti saatavilla, ja sitä varten on yleensä ostettava lisenssejä hosting-palveluntarjoajan kautta, mikä lisää hieman monimutkaisuutta.

Tuotantopainosten edut kehitystyössä:

• Kehität ja testaat ympäristössä, joka muistuttaa tuotantoympäristöä, mikä on lähes aina hyvä asia kehittäjille.

Tuotantopainosten negatiiviset puolet kehitystyössä:

• Edellyttää täydellisen vakioasennuksen uuden instanssin luomiseen: Tämä vie aikaa asentamiseen ja päivittämiseen ja melko paljon levytilaa instanssia kohden
• Lisensointi ei ole selkeä ja vaatii tarkistamista Microsoftin lisenssiedustajalta

Azure SQL Database

Pilvipalveluntarjoajien käyttäminen tietokantojen isännöintiin voi olla todella järkevää kehitystyötä ja testausta tehtäessäsi, mutta niillä on myös joitakin huonoja puolia. Sen hinnan lisäksi, joka sinun on maksettava niiden käytöstä, sinun on myös ymmärrettävä, että koneesi ja tietokannan välinen viive on tyypillisesti huomattavasti korkeampi kuin paikallisen tai jopa LAN-paikallisen instanssin. Tarvitset myös pysyvän yhteyden tietokantaan, joten illan työmatkat, joilla viimeistelet työn junassa, ovat epätodennäköisiä.

Käyttö puhtaasti kehitystyöhön, jossa otat jatkuvasti käyttöön muutoksia ja suoritat komentosarjoja, ei luultavasti ole ihanteellista, mutta ne voivat todella hyötyä testauksessa, erityisesti osana automatisoituja testisarjoja, jotka toimivat isännöidyissä palveluntarjoajissa, kuten Appveyorissa tai VSTS:ssä.

Kyky luoda uusi instanssi, ottaa koodi käyttöön ja suorittaa testit on loistava jatkuvan integraation (ci) prosessissa, jotta voit suorittaa useita rakennuksia samanaikaisesti ilman, että sinun tarvitsee ylläpitää tiettyä instanssia tai tietokantaa jokaista rakennusta varten – kun siirryt yhteen rakennukseen osana ci-prosessiasi, tämä yksinkertainen lähestymistapa tietokantojen käyttöönotossa todella auttaa.

Azure SQL Database -tietokannan edut kehitystyössä:

• Yksinkertaisuus uusien tietokantojen perustamisessa, varsinkin kun tämä voidaan automatisoida
• Ei kehitystyön instanssien ylläpitoa, joten ei korjauksia, varmuuskopioita jne.

Azure SQL Database -tietokannan negatiiviset puolet kehityksessä:

• Sopii paremmin testaukseen kuin kehitykseen, koska tarvitaan jatkuva yhteys ja se on hitaampaa kuin paikallinen kehitys
• Joudut maksamaan tietokannan käyttöminuuttia kohden

Kontissa oleva versio mistä tahansa versiosta

Windows 2016:ssa ja SQL Server 2016:ssa on molemmissa tuki SQL Serverin ajamiselle konttitallennuksessa. Th-s antaa meille kaiken sen joustavuuden, jonka saamme LocalDb:n ja Azure+AWS:n avulla instanssien nopeaan käynnistämiseen ja pysäyttämiseen. Meidän pitäisi myös nähdä etuja siitä, että meidän ei tarvitse korjata jokaista instanssia erikseen, kunhan käytämme yhteisiä kuvia instansseillemme.

Windows 2016 on nyt julkaistu, joten voimme nyt mahdollisesti luoda ja heittää pois SQL Serverin instansseja (varmasti SQL Server 2016:n) melko yksinkertaisesti, jos meillä on Windows 10 tai Windows 2016. Jos olemme sidottuja aikaisempaan Windows- tai SQL Server -versioon, toimivan kuvan luominen ei välttämättä ole yhtä yksinkertaista.

Kun saamme kontit laajasti käyttöön Windowsissa, sen pitäisi tarkoittaa, että voimme luoda uusia instansseja ja käynnistää ja lopettaa instansseja ilman pitkää asennusprosessia. Tässä vaiheessa näyttää siltä, että instanssien käynnistäminen ja pysäyttäminen on hitaampaa kuin LocalDb:n tapauksessa.

Jos testaat tietokantojasi pilvimäisessä ympäristössä, kuten Microsoftin VSTS-palvelussa, saatat myös huomata, että LocalDb-instanssin käynnistäminen on mahdollista, koska se on jo asennettu. Sen sijaan SQL Server 2016 -tietokantakuvan lataaminen ja sen käynnistäminen saattaa viedä liikaa rakentamisminuutteja.

Johtopäätös

Kehittäessämme koodia SQL Server -tietokantoja varten meillä kehittäjinä on kolme päävaatimusta:

• Me haluamme olla tuottavia mahdollisimman nopeasti;
• Haluamme, että ympäristömme on mahdollisimman yksinkertainen;
• Emme erityisesti halua luottaa hyviin Internet-yhteyksiin;
• haluamme käyttää testiversiota, joka simuloi reaalimaailmaa toiminnallisuuden kannalta (ei välttämättä suorituskykyä päivittäisen kehityksen kannalta)

LocalDb on tyypillisesti vastaus useimmille SQL Server -kehittäjille, ja jos sinulla ei ole erityisiä vaatimuksia, joiden vuoksi et voi käyttää sitä, suosittelen sitä voimakkaasti.