Recent Posts

Archives

Categories

Meta

SQL technológiák és felhasználásuk

Nagyra becsült kollégám szokta mondani, hogy más utasítás nincs is, mint az a négy DML (SELECT,INSERT,UPDATE,DELETE), amit gyakorlatilag még az ősidőkben SQL-92 szabványként hoztak létere. Neki már a JOIN felesleges. Megbocsátható egy hardware-esnek, akinek elég pár regiszter és azzal már csodákra képes.

Ehhez képest nézzük meg milyen tempóban jönnek ki az SQL szerver újabb verziói.

Az első, ami még nem az őskorban született a 2000-es, majd 2005-ös, 2008-as, aztán két évente. Mi a fenének arra a 4 parancsra?

Az egy dolog, hogy rettenetesen sok új tulajdonsággal vették körbe azt a bizonyos 4 parancsot, ami ma már 5 a MERGE megjelenésével, illetve a teljesítményt fokozták különböző technikákkal. Bevezettek jó pár szolgáltatást, amiről már én is írtam a blogokban illetve a cikkekben.

Ebben a cikkben szeretném egy kicsit megvilágítani, hogy pl. egy konkrét szoftver termékben miként lehet ezeket kihasználni.

Vegyünk például egy HR rendszert, amit különböző cégeknek szeretnénk eladni, tehát számtalan környezetben kell üzembe helyezni. Az alap, hogy elkészítjük a rendszert a megfelelő adatbázis- és szoftver komponensekkel. Mondjuk minden jól megtervezett és alaposan tesztelt, olyan, amilyennek megálmodtuk. Igazából, ha minden cég ugyanolyan lenne, és nem lennének egyedi igényei, vagy mi azt nem is szeretnénk megvalósítani, akkor egy kiváló dobozos terméket tudunk előállítani. Csak sok-sok példányban kell eladni és dől a lé. De tudjuk, hogy a konkurencia sem alszik, így már nem csak mi vagyunk a piacon, kénytelenek vagyunk rugalmasak lenni és egyedi igényekre is gyúrni kell, illetve meg kell próbálni az igényeket általánosan megoldani.

A fenti bevezető után nézzük, milyen extra dolgokat, milyen technológiákkal tudunk támogatni. Itt kifejezetten az adatbázis szerver nyújtotta támogatásokat emelem ki.

Többnyelvűség (XML, Computed Column):

Két dolgot lehet kihasználni. Az egyik a felhasználó nyelvi beállítását (2014 előtt login szinten lehetett ezt megadni, most már user szinten is). A másik a natív xml támogatás. A program összes szövegét tárolhatjuk egy táblában, ahol minden szöveg objektum egy sornak felel meg. A sorban az objektum azonosító mellett egy xml oszlop tartalmazza a szöveg  összes nyelvi megfelelőjét. Már csak egy computed column kell, ami az xml-ből a user nyelvi beállításának megfelelően (@@language) visszaadja a megfelelő lefordított szöveget.

DECLARE @xmlInput AS XML = '<LNG HU="magyar" EN="english" />'
SELECT
T.C.value('@EN', 'nvarchar(80)') as MSG
FROM @xmlInput.nodes('LNG') T(C)

Hosszú ideig futó riportok (SB):

Ez esetben a Service Broker tud segíteni. Írnunk kell egy tároltat, ami elkészíti a riportot egy temp táblába. A tároltat hívja meg az SB, ha érkezik egy parancs a QUEUE-ba.

A folyamat a következő:

  1. Elindítjuk a programból a riportot.
  2. Az indítás egy SEND parancsot ad az SB-nek. A parancsban (ami egy xml vagy JSON) paraméterezhetjük a futtatandó riport beállításait (szűréseket). A riport állapotát futás alattira állítjuk.
  3. Az SB meghívja  a tároltat, és ha végzett, akkor a riport állapotát készre állítja.
  4. A program észleli a riport kész állapotát és megjeleníti az eredményt a temp táblából.

Szűrt adatbázis az aktuális  felhasználó alapján (Schema):

Itt a séma tud segíteni nekünk. Legyen pl. minden tábla a dbo sémában. Ha egy felhasználó default sémája dbo, akkor ő szűrés nélkül láthatja a táblákat. A szűréshez vegyünk fel egy SZURO nevű sémát. Itt minden dbo-ós táblára definiáljunk view-t, ami a sorokban rögzített users oszlopa alapján visszaadja vagy kiszűri a sort. (A lenti példa csak szemléltetés).

SELECT * FROM TABLA WHERE USERS LIKE SUSER_NAME()

Lényeg az, hogy minden felhasználónak a default sémája a SZURO séma kell hogy legyen.

2016-os fejlesztésben már létezik a “Row Level Security”, ez egy lehetséges alternatíva (lehet, hogy az Express nem tartalmazza majd).

Változások továbbirányítása más rendszernek (Change Tracking, SB):

Ez esetben a Change Tracking technológiát tudjuk alkalmazni. Erről már írtam egy cikket, technikailag ezt most nem részletezem. Lényeg az hogy azokra a táblákra kell beállítani a change traking-et, amelyeken a változásokat követni akarjuk, és ütemezetten tudjuk továbbküldeni a más rendszer(ek)nek. Leginkább arra szolgál, hogy nagyvállalati környezetben ne kelljen az azonos adatokat több rendszerben is rögzíteni. Általában a személyeket a HR rendszerben veszik fel, majd innen tovább lehet küldeni a személyi adatokat az összes többi rendszernek, amelynek szintén részét képzi a személyi állomány. Természetesen ezt a technológiát ötvözhetjük az előbb említett Service Broker-el. Táblánként külön parancsot küldünk az SB-nek, amit az tovább küld egy másik szerver SB-jének. Az SB parancs létrehozásához a tábla sorának adatait ilyen egyszerű módon lehet xml-re alakítani:

SELECT * FROM TABLE FOR XML AUTO

Replikációk (Replication):

Ez már nagyon régen része az Sql Servernek, de jelentősége egyre csökken, mivel a hálózatok sebessége és ára is csökkenti a jelentőségét. Mindenesetre az erőforrások elosztásában sokat tud segíteni. Például mondjuk egy áruházláncnál, ahol az egyes áruházaknak saját szerverük van, és helyileg kezelik az adataikat. Az összes áruház adatai egy központi szerverre (publication) kerül, ő végzi az összes telephelyi szerver (subscription) szinkronizációját. Leginkább a Merge és a Tranzakcionális replikáció hasznos.

A Merge leginkább a több telephelyes rendszereknél elterjedt, ahol jól szétválaszthatók a területek és egymás területeit nem is igen kezelhetik, így kevesebb a konfliktus. A konfliktusok feloldását viszont kezelni kell, erre külön felületet ad az SQL Server.

A Tranzakcionális replikáció a gyors szinkronizációt szolgálja, ahol elég gyorsan kell frissíteni az adatokat a rendszerek között. Itt viszont táblánként meg kell adni, hogy melyik rendszer szolgáltatja az adatokat, a többi rendszer csak előfizető.

A Snapshot replikációt akkor tudjuk használni, ha a központi gép adatbázisát időnként pl. egy Laptopra szeretnénk kitenni, hogy tudjunk vele dolgozni off-line módon. Természetesen a Lapton történő módosítások nem tudnak visszakerülni a szerverre, de erre nincs is szükségünk (erre a Merge szolgál).

Program rendszer modularizálása (Schema, Synonym):

Egy program rendszer általában több modulból is állhat. Ha szeretnénk ezeket elkülöníteni, hogy könnyebben átlátható legyen, vagy funkcionálisan is ez adja a megoldást, akkor használjuk a sémákat. A szűrt db-nél már írtam, hogyan lehet ezt kivitelezni a séma segítségével. Nagy előnye a sémának, hogy újradefiniálhatók az objektumok. Pl. a dbo sémában van egy teszt táblánk, az a tábla létezhet egy proba nevű sémában is. Természetesen az elérések különbözőek: dbo.teszt illetve proba,teszt. Ha viszont a csak moduláris szétbontás van, pl. modul1 és modul2 séma névvel, akkor a dbo ezeket nem éri el. A programokban ez esetben a schema.object teljes hivatkozással kell hivatkoznunk. Ha nem akarjuk ezt, akkor a sysnonym paranccsal létrehozhatjuk a dbo.object-et, ahol a dbo elhagyható.

Rugalmasságot tudunk kölcsönözni a rendszerünknek, ha például minden objektumunkat egy külön sémába vesszük fel és a dbo sémába beemeljük az összeset a CREATE SYNONYM paranccsal. Így bármikor megtehetjük, hogy pl. a szinonimát view-ra cseréljük, ha esetleg ez szükséges. Szóval a séma és a szinonima rengeteg lehetőséget rejt magában.

Leave a Reply