• Bevezetés
• Milyen lehetőségek vannak, amelyeket fejlesztési munkához használhatunk?
• Mire vágynak a fejlesztők?
• Mennyire különböznek a kiadások
• A választás befolyásolja a használt eszközöket?
• LocalDB
  • A LocalDb előnyei a fejlesztésben
  • A LocalDb hátrányai a fejlesztésben
• Milyen más kiadások vannak?
  • Express Edition
  • Developer Edition
  • Web, Standard, és Enterprise Editions
  • Azure SQL Database
• Minden kiadás konténeres változata
• Végkövetkeztetés

Előszó

Fejlesztőként szükségem van egy SQL Server adatbázisra, amelyhez kódot tudok fejleszteni és tesztelni. Számos lehetőség közül választhatunk, és különböző kérdéseket kell szem előtt tartanunk. Ebben a cikkben megvizsgáljuk a választási lehetőségeket, és a meghozandó döntéseket. Az SQL Server LocalDb kiadása úgy jött létre, hogy a fejlesztők számára a legkézenfekvőbb kiadás legyen; Van-e ennek az elképzelésnek gyakorlati értelme, és milyen alternatív előnyei vannak a fejlesztők számára a többi kiadásnak?

A fejlesztői munka általában több szerverpéldányt igényel. Ezeket egy szerveren kell megosztani, vagy több szerveren vagy virtuális gépen kell elosztani? Minden fejlesztői szervernek azonos kiadásúnak kell lennie? Bölcs dolog-e internetkapcsolatra támaszkodni, hogy az összes fejlesztőkiszolgálót a felhőben alapozzuk, vagy van helye a hagyományos “SQL Server a laptopon”

Az SQL Server 2005 előtt nem volt nehéz kiválasztani azt a kiadást, amellyel a fejlesztést végezzük. Magán a terméken kívül csak egy ingyenes fejlesztői kiadás volt. Ez aztán bonyolultabbá vált, és egyre bonyolultabbá válik, és a Windows 2016 és az SQL Server 2016 konténerek bevezetésével néhány érdekes permutáció jön a fejlesztők számára.

Milyen lehetőségek vannak, amelyeket fejlesztői munkára lehet használni?

Pillanatnyilag vannak:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure. adatbázis + Amazon RDS
• Containerizált változata bármelyik kiadásnak

Létezik egy Compact Edition nevű kiadás is, amely már elavult, de még mindig elérhető. Ez némi hasonlóságot mutat az SQL Serverrel, de nagyon kis alapterületű, és folyamaton belül fut. A Compact Edition egy SQL dialektust futtat, de nem az SQL Server kiadása. Valójában nem megfelelő fejlesztői példány az SQL Serverre telepítendő kód fejlesztésére és tesztelésére.

Mit akarnak a fejlesztők?

1. Termelékenység
   Adatbázisfejlesztőként akkor vagyok a legtermékenyebb, ha saját példányom van a saját gépemen, amelyet tetszés szerint állíthatok le, indíthatok el, dobhatok el és hozhatok létre. Amikor az adatbázis vagy a példány egy megosztott szerveren van, akkor úgy találom, hogy a fejlesztés lassabb – vagy mások változtatnak meg dolgokat, amelyeken én dolgozom, vagy más dolgokat tesznek, hogy megszakítsák azt, aminek gyorsnak kellene lennie, a fejlesztés, telepítés és tesztelés ciklusát.
2. Egyszerűség
   A fejlesztőnek szabadon kell töltenie az idejét a kód írásával, tesztelésével és hibakereséssel, és az olyan erőforrások, mint az SQL Server-adatbázisok kezelésével töltött idő azt jelenti, hogy kevesebb ideje marad a ténylegesen hasznos dolgokra, amelyek értéket jelentenek az üzlet számára.
3. Pontosság
   Egy ideális világban minden fejlesztőnek lenne egy gyors, helyi, pontos másolata a termelési adatoknak, olyan adatokkal, amelyek a lehető legközelebb állnak a termelési adatokhoz. Ennek segítségével tesztelhetik, hogy a változtatásaik ugyanúgy viselkednek-e a termelésben, mint a fejlesztői környezetben. Biztosan számtalan olyan alkalmazás létezik, amely szupergyorsan működik egy fejlesztői gépen, de lassabban, ha 3 rétegű architektúrában telepítik, ahol sok a késleltetés és a szolgáltatások közötti hálózati hívás. Azt is fontos ellenőrizni, hogy az egyik adatbázisra írt kód valóban fut-e egy másik adatbázisban. Ha a termelésben SQL Server 2008 R2 lenne, akkor semmi értelme nem lenne az SQL 2016-tal fejleszteni a memórián belüli táblák használatával.

Mennyire különböznek a kiadások?

Egy adatbázis-alkalmazás fejlesztése és tesztelése során gyakran fontos tudni, hogy ha kódot írunk, és látjuk, hogyan viselkedik a fejlesztés során, akkor a termelésben is hasonló viselkedést fogunk kapni. A kiadásokat a telepített és engedélyezett funkciók határozzák meg; az alapmotor kódja ugyanaz, akár az ingyenes, akár az enterprise kiadás valamelyikét használjuk. A probléma akkor merül fel, amikor mondjuk egy csak vállalati funkciót használunk a fejlesztés során, de a termelésben csak egy Standard kiadású példányunk van. A kiadások teljes összehasonlítását a Microsoft itt teszi közzé: “Az SQL Server 2016 kiadásai által támogatott funkciók”

A választás befolyásolja a használt eszközöket?

A magmotor és a nyelv szempontjából minden példány ugyanúgy viselkedik; ha tehát van olyan eszközünk, amely képes kezelni az Enterprise kiadást, akkor elvileg minden más kiadást is képes kezelni. Régebben nem minden eszköz tartotta be ezt az elvet: volt egyszer egy SQL Management studio SQL Expresshez készült verziója, amelyik úgy volt korlátozva, hogy nem tudta kezelni a teljes kiadás funkcióit. Most az SQL Server Management Studio visszafelé kompatibilis a korábbi verziókkal, és oldalirányban kompatibilis az összes kiadással. Jelenleg ingyenesen letölthető, így bármelyik példányt kezelheti anélkül, hogy teljes licencre lenne szüksége.

A második korlátozás az, hogy a LocalDb használatához meg kell változtatni az SQL klienskönyvtárat, így az SQLOLEDB és a .Net régebbi verziója nem tud csatlakozni – ha olyan alkalmazással rendelkezik, amelyet .Net 4-es verziónál korábbi, akkor előfordulhat, hogy nem tud csatlakozni.

Milyen kiadások közül választhatunk a fejlesztéshez?

LocalDb

Hacsak nincs olyan speciális követelmény, amelyet a LocalDb nem tud teljesíteni, akkor ez kell, hogy legyen az első választás a fejlesztők számára. Nézzük meg, mi is ez, majd nézzük meg, milyen előnyöket kínál.

A LocalDb az SQL Server egy lecsökkentett változata, amelyet kifejezetten úgy terveztek, hogy könnyű legyen, és könnyen és gyorsan lehessen indítani és leállítani. Ez kompromisszumot jelent, ezért bizonyos korlátozásokkal jár, de a legtöbb fejlesztő számára valóban nagyszerű választás, mert gyorsan létrehozhat, használhat és megsemmisíthet egy adott felhasználóra jellemző példányokat.

A LocalDb-nek van néhány további előnye: Így nem kell sok lemezterületet felhasználnia minden egyes példányhoz, amelyre szüksége van. Ez azt jelenti, hogy nagyon egyszerű elindítani egyet, ha egy fejlesztési munkamenet hevében úgy találjuk, hogy új példányra van szükségünk.

A LocalDb létrehozása egyszerű: Csak a következőket kell beírni a parancssorba:

Ez létrehoz egy új példányt, amelyet “instance name” néven használhat, az én gépemen kb. 4 másodpercig tart egy új példány létrehozása, majd még kb. 2 másodpercig tart a példány elindítása. Az SQL Server bármely más típusú új példányának telepítése percekben és órákban mérhető.

Ha a LocalDb több verziója is telepítve van, akkor ezek bármelyikét nagyon egyszerűen létrehozhatja, ha csak ezt a kódot hajtja végre a parancsértelmezőben:

Egy ilyen listát fog kapni:

Ezután, ha egy 2012-es példányra van szükséged, be kell írnod:

Ezután egy új SQL Server 2012 példányt kapunk, amelyhez csatlakozhatunk.

A LocalDb-hez való csatlakozás egy kicsit más, mint a hagyományos példányhoz való csatlakozás: Ahelyett, hogy a gép nevéhez csatlakoznál, és vagy egy portot vagy a példány nevét adnád meg, a “(localdb)” szót, majd a példány nevét adod meg, tehát ha a példány neve “test-instance”, akkor ezt adnád meg a szerver neveként:

Hogy megtudja, hogy milyen példányai vannak, használhatja a következőt:

:

Ez felsorolja a LocalDb példányokat, egy további vizsgálatához adja meg a példány nevét az utolsó parancshoz, mint pl.:

Ez a LocalDb példányok listája:

A kimenet a következő lesz. a

• név
• verzió
• melyik felhasználóhoz tartozik
• indult-e vagy sem
• az utolsó indítási idő

Ha elindult, megadja a megnevezett cső elérési útvonalát is, amelyen fut. Ha olyan kliensed van, amelyik nem érti a (localdb) szervernevet, akkor esetleg névre szóló csöveken keresztül tudsz csatlakozni a példányhoz.

A localDb nagyszerű a fejlesztés ellen, mert olyan gyors a példányok létrehozása és indítása, ha gyakran dolgozol különböző projekteken, akkor leállíthatod és elindíthatod a példányokat, és sok különböző példány áll rendelkezésre anélkül, hogy a karbantartásukkal és a lemezen való tárolásukkal járó többletköltséget kellene viselned. Nyilvánvalóan ugyanazok a hátrányai, mint az Expressnek, hogy ezek az SQL Server lecsökkentett változatai. Nincs például teljes szöveges indexelés, ami miatt egyes alkalmazásokban nem használhatók.

A LocalDb előnyei a fejlesztés számára:

• Gyors fejlesztés, egyszerűen létrehozhatók új példányok a fejlesztéshez és a teszteléshez.
• Megosztja a binárisokat az azonos verziójú példányok között, így nem foglal sok lemezterületet, és nem kell sok különböző verziót fenntartani

A LocalDb negatívumai fejlesztésre:

• Nem tartalmaz néhány alapvető funkciót, mint például az SQL Agent
• nem támogatja a FILESTREAM-et
• nem lehet merge replikációs előfizető,
• csak a Service Broker számára engedélyezi a helyi várólistákat.
• mindig a felhasználó biztonsági környezetében fut;

Milyen más kiadások léteznek?

Express Edition

Az Express edition az SQL Server ingyenes változata, amelyet kis számú felhasználóval rendelkező kis adatbázisok számára terveztek. A 2016-os verzióban az Express négy magra, példányonként 1 GB RAM-ra és 10 GB-os maximális adatbázisméretre korlátozódik. Bár ez egy elfogadható méret, a legtöbb termelési adatbázis-alkalmazáshoz nem elég nagy, de a fejlesztési munkákhoz hasznos, ha a fejlesztői példány nem igényel sok erőforrást és kicsi, valamint ha nem fejleszt olyan funkciókat, amelyek a Standard vagy Enterprise-only funkcióktól függenek..

Az Express előnyei fejlesztésre:

• A teljesítményproblémák szembetűnőbbek lesznek a fejlesztés során
• Nincsenek licencbonyodalmak a fejlesztési munkához
• Egyéni és közös fejlesztésre egyaránt alkalmas.
• A hálózati szolgáltatások ugyanúgy konfigurálhatók, mint a teljes kiadásoknál, így távoli gépekről is lehet tcp-vel csatlakozni, és az SQL Browser szolgáltatás segítségével a példánynév alapján is engedélyezhető a csatlakozás
• Szabadon letölthető és telepíthető

Az Express negatívumai fejlesztésre:

• Nem tartalmazza az egyik produkciós verzió teljes funkciókészletét
• Új példány létrehozásához teljes szabványos telepítésre van szükség, ez időt vesz igénybe a telepítéshez és frissítéshez, és elég sok lemezterületet igényel példányonként
• Nem használható terhelés- vagy teljesítménytesztelésre

Developer Edition

A fejlesztői kiadás az SQL Server teljes értékű Enterprise kiadása, amelyből minden korlátozást eltávolítottak. Ez nagyszerű, ha olyan alkalmazást fejleszt, amely az Enterprise kiadást használja, de ha olyan alkalmazást fejleszt, amely a Standard kiadást használja, akkor előfordulhat, hogy jobb teljesítményt kap, mint a termelésben, vagy olyan funkciót használ, amely csak a vállalati kiadásra vonatkozik. Költséges hiba lehet kódot fejleszteni, hogy aztán a telepítéskor kiderüljön, hogy az nem futtatható.

Ha egyetlen adatbázis-alkalmazáson dolgozik, és egy meglévő, Enterprise kiadást használó szerverre telepíti, akkor nem járhat rosszul, ha az SQL Server fejlesztői kiadását használja.

Az SQL Server 2000 licencelése azt jelentette, hogy a fejlesztői kiadás ingyenes volt, amíg a felhasználás fejlesztésre és tesztelésre, nem pedig termelési adatbázisként történt. Ha úgy döntött volna, hogy a fejlesztői kiadást termelésre használja, akkor a vállalati kiadáshoz hasonlóan kellett volna árazni. Az SQL 2005 megjelenésekor a licencelés módosítása azt jelentette, hogy a fejlesztői kiadás használatáért fejlesztőnként 50 dollárt kellett fizetni. Ez azt jelentette, hogy sokan nem tudták használni a fejlesztői verziót, különösen azokban a csapatokban, ahol a fejlesztők csak ritkán használták az SQL-t, vagy ahol nem rendelkeztek MSDN-előfizetéssel, amely a fejlesztőket a fejlesztői kiadás licencével látta el. Ez különösen feltűnő volt a nem .net-es csapatoknál, amelyek történetesen SQL Server-t használtak.

Az SQL Server 2016 licencelési útmutatója szerint “Az SQL Server Developer Edition nem használható termelési környezetben vagy termékadatokkal” – feltételezve, hogy a “termékadatok” alatt “termelési adatokat” értünk, akkor úgy tűnik, hogy nem lehet biztonsági mentést készíteni és visszaállítani egy termelési adatbázist teszteléshez, hacsak nem licenceljük a szervert termelési szerverként. Az útmutatóban az is szerepel, hogy a fejlesztői kiadás ingyenesen használható, ha csatlakozik a “Dev Essentials” programhoz – ha más kiadásra, például Enterprise vagy Standard kiadásra van szüksége a fejlesztéshez/teszteléshez, akkor a “Visual Studio” előfizetéssel férhet hozzá.

A fejlesztői kiadás előnyei fejlesztésre:

• A fejlesztői kiadás egy teljes értékű Enterprise kiadás, így ha tesztel és működik a fejlesztői kiadáson, akkor a kódnak ugyanúgy kell viselkednie, mint a produktív Enterprise szerveren.

A fejlesztői kiadás hátrányai fejlesztésre:

• Csak az Enterprise kiadáshoz való adatbázis fejlesztésére alkalmas. Mivel a Developer edition néhány funkciója és viselkedése hiányzik a Web vagy Standard Editionből, a produktív rendszere kevesebb funkcióval fog rendelkezni, mint a fejlesztői környezet, ami soha nem jó ötlet.
• Meglehetősen sok lemezterületet használ példányonként
• A licencelés nem egyértelmű, ezért a Microsoft licencelési képviselőjével való egyeztetés szükséges

Web, Standard és Enterprise kiadások

Ezek a verziók mind licencet igényelnek a termelésben való használathoz. A webes kiadást csak alkalmazás hosting szolgáltatókon keresztül lehet megvásárolni. Gyakran a legbiztonságosabb, ha az SQL Server azon kiadása ellen fejlesztünk, amelyre telepíteni fogjuk, minden bizonnyal bármilyen teljesítmény- vagy skálázhatósági teszthez, ha nem is a mindennapi fejlesztéshez. A fejlesztői kiadással kapcsolatban tárgyaltak szerint a licencelés kissé homályos, és előfordulhat, hogy fizetnie kell a licencért, ha valamelyik kiadást fejlesztői vagy tesztkörnyezetben használja.

A webes kiadás nem érhető el általánosan, és általában egy tárhelyszolgáltatón keresztül kell licenceket vásárolni hozzá, ami némi további bonyolultságot jelent.

A fejlesztésre szánt production kiadások előnyei:

• Egy olyan környezetben fejleszthet és tesztelhet, amely hasonló a productionhoz, ami a fejlesztők számára szinte mindig jó dolog.

A fejlesztésre szánt production kiadások hátrányai:

• Új példány létrehozásához teljes standard telepítésre van szükség:
• A licencelés nem egyértelmű, és egyeztetni kell a Microsoft licencelési képviselőjével

Azure SQL Database

A felhőszolgáltatók adatbázishoz való felhasználása a fejlesztés és tesztelés során valóban értelmes lehet, de vannak hátrányai is. A használatukért fizetendő ár mellett azt is meg kell értened, hogy a géped és az adatbázis közötti késleltetés jellemzően jelentősen nagyobb lesz, mint egy helyi vagy akár LAN helyi példány esetében. Emellett állandó kapcsolatra is szüksége lesz az adatbázissal, így az esti ingázás, amikor a vonaton fejezi be a munkát, valószínűtlen.

Ezek használata tisztán fejlesztési munkára, ahol folyamatosan változtatásokat telepít és szkripteket futtat, valószínűleg nem ideális, de tesztelésre nagyon jól használhatóak, különösen olyan automatizált tesztkészletek részeként, amelyek olyan hosztolt szolgáltatókban futnak, mint az Appveyor vagy a VSTS.

Az új példány létrehozásának, a kód telepítésének és a tesztek futtatásának képessége nagyszerű a folyamatos integrációs (ci) folyamathoz, így több buildet is futtathat egyidejűleg anélkül, hogy minden egyes buildhez külön példányt vagy adatbázist kellene fenntartania – ha egyszer átmegy az egyetlen buildre a ci folyamat részeként, akkor az adatbázisok telepítésének ez az egyszerű megközelítése valóban segít.

Az Azure SQL Database előnyei a fejlesztéshez:

• Egyszerűség az új adatbázisok létrehozásában, különösen mivel ez automatizálható
• Nincs szükség a fejlesztési példányok karbantartására, így nincs javítás, nincs biztonsági mentés stb.

Az Azure SQL Database negatívumai fejlesztésre:

• Tesztelésre alkalmasabb, mint fejlesztésre, mivel állandó kapcsolatra van szükség, és lassabb lesz, mint a helyi fejlesztés
• Az adatbázis használatáért percenként kell fizetni

Minden kiadás konténeres változata

A Windows 2016 és az SQL Server 2016 is támogatja az SQL Server konténerben történő futtatását. Ez biztosítja számunkra mindazt a rugalmasságot, amit a LocalDb és az Azure+AWS esetében kapunk a példányok gyors indításához és leállításához. Azzal az előnnyel is számolnunk kell, hogy nem kell minden példányt külön-külön foltoznunk, amennyiben közös képeket használunk a példányainkhoz.

Már megjelent a Windows 2016, így most már potenciálisan elég egyszerűen létrehozhatjuk és eldobhatjuk az SQL Server példányait (természetesen az SQL Server 2016-ot), ha van Windows 10 vagy Windows 2016. Ha a Windows egy korábbi verziójához vagy az SQL Server egy korábbi verziójához vagyunk kötve, akkor nem biztos, hogy olyan egyszerű lesz egy működő képet létrehozni.

Mihelyt széles körben elterjednek a konténerek a Windowsban, akkor ez azt jelentené, hogy hosszadalmas telepítési folyamat nélkül hozhatunk létre új példányokat, indíthatunk és állíthatunk le példányokat. Ebben a szakaszban úgy tűnik, hogy a példányok indítása és leállítása lassabb lesz, mint a LocalDb esetében.

Ha az adatbázisokat felhőszerű környezetben, például a Microsoft VSTS szolgáltatásában teszteljük, akkor a LocalDb példány indítása is megvalósítható, mivel az már telepítve van. Ezzel szemben az SQL Server 2016 adatbázis-kép letöltése, majd elindítása túl sok időt vehet el a build percekből.

Következtetés

Az SQL Server adatbázisokhoz való kódfejlesztés során nekünk, fejlesztőknek három fő követelményünk van:

• a lehető leggyorsabban akarunk produktívak lenni;
• a lehető legegyszerűbb környezetet szeretnénk;
• nem akarunk különösebben a jó internetkapcsolatra támaszkodni;
• olyan tesztverziót szeretnénk használni, amely a valós világot szimulálja funkcionalitás szempontjából (nem feltétlenül a napi fejlesztéshez szükséges teljesítményt)

A legtöbb SQL Server fejlesztő számára jellemzően a LocalDb a megoldás, és hacsak nincs olyan speciális követelménye, ami miatt nem tudja használni, nagyon ajánlom.