Mi alapján választunk a relációs adatbázisok közül?
A relációs adatbázisok kötelezően elvárható és opcionális képességei

Ez egy meghatározó kérdés, főleg annak tükrében, hogy az esetek többségében az informatikai költségek nagyobb részét adatbázis kezelő rendszerre költik.

A licenszet jellemzően a felhasználók számától, vagy a hardver méretétől teszik függővé a gyártók, ez milliós-tízmilliós-százmilliós nagyságrendet jelent a hardvermérettől függően, továbbá függ a processzorok számától, alternatív felhasználók számától. Rengeteg opcionális elem van (pl. Diagnostic Pack), ezek is befolyásolják a költséget. 

Az olcsó, ingyenes adatbázis kezelő rendszerek esetében magas support díjat kell fizetni.

Elvárható, hogy ilyen ne történjen a szoftver hibájából. Előfordulhatnak azonban például lemez meghibásodások, hálózati megakadások, amelyek problémákhoz vezethetnek, de főleg a fájlok elvesztése okozhat súlyos adatvesztési problémákat. Akármilyen erősen védett a rendszer ezek ellen, akkor is előfordulhat annyi egy időben bekövetkezett meghibásodás, hogy adatvesztés forduljon elő. Például egy bank esetében óriási bizalomvesztéssel járna akár néhány tranzakció elvesztése az adatbázisból. Ennek ugyan kicsi a valószínűsége, de hatalmas üzleti kárt okoz, ha bekövetkezik, így ezt is a költség részének kell tekinteni.

Évente minden cégnél történik legalább egy-két tervezetlen állásidő, tervezett pedig ennél jóval több. Ezeknek is megvannak az üzleti kárai. A tervezett állásidő esetén kisebb az üzleti kockázat, hiszen előre be tudják jelenteni. Az előre be nem jelentett leállás ennél nagyobb problémát okozhat.

Gyakran jelentősen függ attól, hogy milyen adatbázis kezelő rendszert használunk, egyesek ugyanis olcsó hardvereken is futnak, léteznek azonban olyan adatbázis kezelő rendszerek, amelyek drága gépeket igényelnek.

Többek között a bérre, és képzésekre fizetett összeg. Egyes adatbázis kezelő rendszerek annyira automatizáltak, hogy kevés üzemeltető szükséges hozzájuk, míg kevésbé automatizált adatbázis kezelők működtetéséhez jelentősen több alkalmazottra lesz szükségünk.

Total Cost of Ownership, a rendszerek birtoklásának a teljes költségét mutatja meg (amerikai bérekkel számolva).

Ezért olyan adatbázis kezelőt kell választanunk, amelynél nem mi fogjuk először megtapasztalni a hibát, tehát sokan használják már, ennek köszönhetően azt a problémát, amivel szembesülünk valószínűleg már korábban is tapasztalták.

Ha például internet banking üzemeltetéséhez keres szoftvert egy cég, akkor irreleváns számára, hogy az adott szoftver mennyire megbízható teljesítményt nyújt a telekommunikációs szektorban. Ha olyan szoftvert választunk, amit mások már ugyanolyan célokra használtak, akkor náluk valószínűleg már fölmerült az az igény, ami nálunk is jelentkezni fog, így a szoftver gyártójának már volt ideje reagálni az adott igényre.

Egy kiforrott, sokak által már használt adatbázis kezelő esetében amennyiben hibaüzenetet kapok, arra elég rákeresni a Google-n, és rengeteg információhoz juthatok róla, míg egy ismeretlen adatbázis kezelő esetén az elsők között szembesülök egy problémával, és rengeteg időmbe, illetve energiámba kerül a probléma elhárítása.

Az elterjedtség és a kiforrottság között van összefüggés, ami azonban nem függvényszerű, ugyanis léteznek kiforrott, de kevésbé elterjedt rendszerek, és vannak néhány éve bevezetett, de széles körben használt adatbázis kezelők is.

Szükség esetén könnyű új munkatársat (elcsábíthatunk embereket a konkurenciától), külső konzultánst találni (nem kell külföldről drágán szakértőt hívni). Jelentősen megkönnyíti a tapasztalatcserét is.

Nemcsak egy adatbázison belül kell megbízhatóan kezelnie a tranzakciókat, hanem két adatbázis kezelő rendszer között is: az adatok áramolnak a rendszerek között, ennek megbízhatónak kell lennie, nem fordulhat elő adatvesztés.

Például Oracle esetén az adatbázis link (database link): az ilyenkor futó szoftverkódot elosztott tranzakciónak (distributed transaction) nevezik és az elosztott tranzakciót úgynevezett kétfázisú jóváhagyási mechanizmussal hagyhatjuk jóvá), ezt viszonylag könnyű megoldani.

Ez jóval bonyolultabb. Az adatbázis kezelőnél nagy fegyvertény, ha birtokában van ennek a képességnek; az Oracle esetében egy nagyon lassú folyamat.

Az IBM dolgozta ki. Két különböző gyártó rendszere közötti adatátvitel általában XA protokoll szerint történik.

Például az adatbázis kezelő rendszer és egy üzenetküldő rendszer között („Messaging System”: üzenettovábbító rendszer, lényege, hogy megbízhatóan befogadja és továbbítsa az adatokat, garantálja, hogy a másik fél elolvasta).

Rendszerint XA protokollon közlekednek az adatok.

Voltak korábban olyan relációs adatbázis kezelő rendszerek, amelyek saját nyelvet használtak, de ezek mára eltűntek, a maiak mind SQL-t használnak, így ennek a nyelvnek több millió ismerője van. Azonban ez nem jelenti az, hogy a programok változtatás nélkül migrálhatóak az adatbázis kezelők között, a relációs adatbázis kezelő rendszerek szabványosítása ugyanis még nem ért el erre a szintre.

Az Oracle azonban gyakran alkalmaz olyan megoldásokat, amelyek túlmutatnak a szabványon, ennek az a hátránya, hogy az így fejlesztett alkalmazásokat nem tudjuk egyszerűen átvinni egy másik gyártó rendszerébe, ez komoly költségekkel jár, sok időt vesz igénybe. A nem szabványos fejlesztése másik kockázata, hogy később megszűnhet a támogatásuk (a jobb adatbázis kezelő gyártókra azonban nem jellemző, hogy megszüntetnek korábban még létező opciókat).

Ezen keresztül kell relációs adatbázisokhoz hozzáférni, SQL utasításokat eljuttatni az adatbázis felé.

Beágyazott SQL ("Embedded SQL") technológiával támogatja a hagyományos programozási nyelveket, ezt úgy kell elképzelni, hogy például a C kód írása közben beírom, hogy „exec sql”, az ez utáni részbe írhatom az SQL szabályok szerinti kódot, amit egy fordító segítségével változtat C kóddá. Példa: https://docs.microsoft.com/en-us/sql/odbc/reference/embedded-sql-example

Hanem Intel, SUN SPARC, Hewlett Packard PA-RISC, és különböző IBM hardverarchitektúrákon is működik.

A virtualzicáiót nem csak elméletben támogatja, hanem baráti árazással is. Például VMWARE virtuális gépen, és egyéb virtuális platformokon is működik az adatbázis kezelő. Ebben az Oracle nem jeleskedik, ugyanis a VMWARE virtuális megoldásai jelentős érdekellentétben vannak az Oracle technológiákkal, az együttműködés megvalósulhatna ugyan, de az kedvezőtlen lenne az Oracle számára, ebből kifolyólag az Oracle licenszelési politikája rendkívül ellenséges VMWARE esetén.

A data szervereknek manapság uralkodó platformja a Linux, de a Windows-os szerverek száma is jelentős. Ezen kívül természetesen még mindig vannak, akik az Intel alapú architektúrákkal szemben a régi nagygépes technológiákat részesítik előnybe, számukra fontos, hogy az adatbázis kezelő fusson Solaris, AIX, HP-UX, esetleg VMS operációs rendszereken is. (Oracle a VMS operációs rendszeren is fut.)

A platformváltás oka lehet egy előre nem látható dolog is, a jó adatbázis kezelő olyan, ahol a szoftver nem külön van megírva Windowsra és külön Linuxra, hanem egy szoftver van, amit át lehet „költöztetni” egyik gépről a másikra, abból, hogy egy platformon fejlesztenek, az is következik, hogy a bug is mindig ugyanott van, és következetesen viselkedik.Ebben az Oracle az élen jár, hiszen ott egy platformon fejlesztenek (Linuxon), és innen visznek át mindent később a többi platformra.

Ez azt jelenti, hogy nem fordulhat elő az, hogy egy alkalmazást csak azért a nulláról újra kelljen tesztelni pusztán azért, mert átköltöztetem egyik platformról a másikra, hiszen ebben az esetben soha nem költöztetnénk az alkalmazást.

Olyan szoftver, ami nem kliens-szerver alapon működik, hanem egy alkalmazás össze van ötvözve az adatbázis kezelővel, kívülről nem is látszik maga az adatbázis, nem igényel a szoftver külön adatbázis kezelő rendszergazdát. Általában kis rendszereket látnak el ilyen megoldásokkal.

Az "Embedded Database" egy válfaja a "Mobile Database” : okostelefonokra, PDA-kon futó rendszerekre gyártják, ez például egy utazó ügynök esetében lehet hasznos, akinek nincs folyamatos kapcsolata a központi adatbázissal, hanem lokálisan viszi be az adatokat a hordozható eszközébe, amely időnként felcsatlakozik a központi adatbázisra, és átadja az adatokat.

Az adatbázisokban manapság már nemcsak szöveget, számokat és dátumokat tárolunk, hanem mindenféle egyéb dolgokat is: Képek, tetszőleges szöveg, térinformatikai adatok, stb.

Először definiáljuk, hogy milyen szerkezetű lesz az xml dokumentum, ennek köszönhetően később a feldolgozás is hatékony lesz. Ha szabadon választott xml formátumot engedélyezünk, az megnehezíti a feldolgozást. Az SQL nyelv önmagában nem elegendő, hiszen nem arra találták ki, hogy xml dokumentumokkal dolgozzon, ezért a gyártóknak nem szabványos elemeket is alkalmazniuk kell az xml feldolgozásának érdekében. Az Oracle képes feldolgozni az xml formátumú adatokat.

Képesség a felhasználó által definiált adattípusok bevezetésére.

Idővel egyre jelentősebb előnnyé válik majd az, hogy nemcsak a saját géptermünkben működtethetjük, hanem bérelhetünk a felhőben is ilyen szolgáltatást: „Platform as a Service”, vagyis PaaS: tehát egy Oracle adatbázis környezetet tudnak például biztosítani. A PaaS nemcsak elméleti lehetőség kell, hogy legyen, hanem a gyakorlatban is olajozottan kell működnie.

A Unicode egy de-facto szabvánnyá vált, támogatása szinte kötelező.  A Unicode legújabb szabványa 9.0. Ebben 128.000 jelből áll a „repertoár” (régen ezt „Character Set”-nek nevezték volna, de ez most nem polkorrekt, ugyanis például a kínai és japán írásjeleket nem lehet karaktereknek nevezni, a repertoár szó általánosabb, ezért ezt használhatjuk).

Az adatbázis kezelő rendszerek ezt preferálják, az amerikai karakterek egy byte-osak, a többi hosszabb, tehát például a magyar ékezetes karakterek két byte-osak, a kínai és japán írásjelek 4 byte-osak.

Két és négy byte-os kódokat is tartalmaz.

Az UTF-16 régebbi változata, két byte-os kódkészlet, 65000 karaktert tartalmazott.

Az SQL nyelv nagyszerű (rengetegen ismerik, nem procedurális, vagyis azt mondom meg neki, hogy mit kell megtalálni, és nem azt, hogy hogyan), de mégis akadnak esetek, amikor más kéne.

Szükségünk lehet algoritmusokra is, és ezek adatbázison belüli tárolására.

Például készíthetnék egy ÁFA nevű függvényt, ami ugyanúgy működne, mint például az átlag, így SELECT-ben is használhatnám.

Megvalósítható lenne például, hogy ne lehessen nagyobb a fizetés, mint az azonos osztályban lévő többiek fizetése.

Rendelkezésre áll az Oracle esetében, rendkívül népszerű.

Kevésbé vált be az Oracle adatbázison belül.

Igen hasznos egy olyan képesség, hogy bizonyos programok maguktól végrehajtódnak (elsülnek) egyes események bekövetkeztekor.

Adatok beszúrása előtt hajtódnak végre, jellemzően a beszúrás ellenőrzéseként használjuk.

Adatok beszúrása után hajtódnak végre. Ezeket gyakran a művelet naplózása érdekében alkalmazzuk.

Ezekkel jellemzően a jobb adatbázis kezelők rendelkeznek.

Hanem például olyanok, amelyek bejelentkezéskor, vagy például a teljes rendszer elindulása vagy leállása esetén futnak le és tesznek előkészületeket, vagy lezáró munkálatokat.

A több millió adatbázis felhasználó cégnek (esetleg embernek) gyakran van olyan közös igénye, amely túlmutat az SQL-en, de mégis praktikus. Ilyen például az ütemezett feladatok végrehajtása (például az adatbázis kezelő rendszerben minden éjszaka történjen valamiféle ellenőrzés), email-ek küldése , fájlok olvasása/írása , üzenetek küldése és fogadása.

Amennyiben létezik procedurális lehetőség az adatbázison belül, akkor rendszerint a gyártó biztosít ilyen kiterjesztéseket, tehát az adatbázis kezelő gyártója készít ilyen szolgáltatásokat, amelyeket a felhasználóik számára rendelkezésre bocsát.

Nyílt forráskódú adatbázis kezelő rendszer esetén ez lehet közösségi fejlesztés is: a felhasználók is gyárthatnak ilyeneket, amelyeket aztán közkinccsé tehetnek.

Előbb utóbb nemcsak összeomlik egy szoftver, hanem adatvesztés is történhet (pl. lemezhiba miatt), a lemezt tükrözhetjük ugyan, de még így is meghibásodhat mind a kettő, vagy akár a felhasználó tévedésből is törölhet egy fájlt.

Az adatbázis kezelő rendszernek olyan mentési mechanizmus kell, amely biztosítja nemcsak a régi mentésre való visszaállást („Restore”), hanem a legfrissebb állapotba való helyreállást is („Recovery”).

A helyreállítás ideje is kritikus (esetleg a helyreállítás ideje alatt nem lehet használni a rendszert): a jó eset manapság néhány perc, a nem jó eset több óra.

 Fontos, hogy a helyreállítás könnyű feladat legyen, ne hibázzunk közben.

Nemcsak a legegyszerűbb hibák, hanem a kellemetlenebb meghibásodások, esetleg többszörös hibák esetére is kell valami forgatókönyv.

Abszolút bombabiztos megoldás mégsem nem létezik, bármikor történhet annyi szerencsétlenség egy időben, hogy adatvesztés történjen.

Nemcsak a ténylegesen várható veszélyekre illik felkészülni, hanem olyan katasztrófa-helyzetekre, amelyek szinte kizártnak tűnnek: tűzvész, árvíz, földrengés, terrortámadás.

Aki katasztrófák ellen is védekezni akar (egyre többen), azok távoli adatbázis-másolatokat szeretnének működtetni, ezt megoldhatja valamilyen hardveres vagy szoftverek távoli tükrözés is, de lehet ez akár az adatbázis kezelő rendszer extra képessége is.

Oracle esetén a DataGuard a katasztrófatűrő megoldás.

A performancia messze nem a legfontosabb, sajnos a korai fázisban mégis sokan ez alapján választanak. Ha a sebesség kiemelkedően fontos, akkor is csak a releváns terheléseket vegyük figyelembe!

Az Oracle ugyan rendre megnyeri a „performancia versenyeket”, de ez nem jelentős információ, ugyanis egy erősebb hardver ellensúlyozhatja a szoftver hatékonyságát, illetve azt is figyelembe kell venni, hogy leginkább a funkcionalitás rovására válik 1-1 adatbázis kezelő rendszer gyorssá, máskor azért gyors egy adatbáziskezelő, mert memóriában dolgozik, és nem merevlemez-alapú. Ez persze sérülékenyebbé teszi, sokkal nagyobb esélye van a tranzakcióvesztésnek ráadásul szinte mindegyik adatbáziskezelő rendszer gyártója kozmetikázza a hatékonysági számait.

Minden újabb verzióról azt mondják, hogy gyorsabb, mint a megelőző verzió, közben rendszerint lassabb, hiszen egyre több funkció kerül az új verziókba.

A sebesség mellett legalább olyan fontos kérdés, hogy ha növekszik a terhelés, tudjuk-e ehhez igazodva növelni a teljesítményt .

Ideális a lineáris skálázhatóság lenne: kétszer annyi hardverrel kétszer annyi munka elvégzése, azonban a lineáris skálázhatóság szinte csak álom.

Oracle esetén a RAC lenne a válasz a skálázhatóságra is.

A „High Availability” egyre fontosabbá válik, egyre gyakrabban van szükségünk 7*24 órás rendelkezésre állásra. Persze valamiféle állásidőnek manapság még ilyenkor is mindenképpen lennie kell. Például az „5 kilences” rendelkezésre állás (vagyis a 99.999%-os rendelkezésre állás) azt jelenti, hogy évente kb. 5-6 percet állunk csupán. Ez nagyon nehezen teljesíthető, de nem lehetetlen, a valóságban azért ennél több állásidő szokott lenni, általában évi 1 óra állásidővel is elégedettek szoktak lenni.

Oracle esetén például a RAC opció a legfőbb magas rendelkezésre állási képesség.

Problémás a következő szoftverek frissítése: operációs rendszer, adatbázis kezelő rendszer, adatszótár: ezek előre bejelentett állásidők.

A merevlemez-alapú adatbázisoknál az adatok a merevlemezen fájlokban tárolódnak. Komoly kockázat, hogy ezeket a fájlokat esetleg ellopják és így jutnak hozzá az adatokhoz. Ezt a komoly adatbázis kezelők úgy védik ki, hogy a fájlban már titkosított módon tárolódnak az adatok. Ilyenkor az INSERT utasítás „titkosítva ír”, és a SELECT utasítás fejti azt vissza. Aki tehát SQL művelettel fér hozzá az adatokhoz, azt ez a titkosítás „nem érinti”. Ugyanilyen titkosítás létezhet a kliens-szerver kommunikáció (hálózati kommunikáció) során is

Az adatbázis kezelő rendszerek zsargonjában auditálásnak nevezik az adatbázis-használat figyelését biztonsági célokból, az adatlopástól tartunk. Azt kell tudnunk, hogy melyik felhasználó mikor milyen műveleteket hajtott végre.

Az auditálás konfigurálható kell hogy legyen: Opcionálisan eldönthető, hogy legyen audit , vagy ne, ezt azért kell eldönteni, mert az audit lassítja a rendszert. Ha van audit, akkor konfigurálható kell hogy legyen annak a részletessége, hiszen minél részletesebb, annál lassabb. Az auditálás működtetése nem lassíthatja számottevően az adatbáziskezelő rendszert.

Lehet auditálni úgy is, hogy az hasznavehetetlen.

Ezzel nemcsak lementhető, hanem egyúttal logikailag ellenőrizhető az adatok tartalma. Előny az, ha ez a program az adatbázis kezelő rendszer belsejébe van beleépítve és nem egy független szoftver.

Hatékony (valószínűleg párhuzamosítható) mentési módszer kell.

Mindent mentsek, vagy csak azt, ami tegnap óta változott.

A mentés elvégezhető legyen online, a rendszer nem állhat le a mentés miatt.

Az adatbázis sebessége ugyan nem a legfontosabb kiválasztási kritérium, de annak mégis hatalmas jelentősége van, ha egy rendszer nagyon precízen monitorozható, és kideríthető róla, hogy hol van a szűk-keresztmetszete. Ha ezután még át is paraméterezhető a működés, úgy, hogy a „bottleneck” eltűnjön, vagy csupán enyhüljön, az már főnyeremény.

Ezáltal ugyanis harmadik fél is gyártani tud monitoring eszközt (nyílt rendszerek).

Egyre több rendszert működtetünk. Egyes cégeknél több száz adatbáziskezelő rendszer működik. Nem tudnak a rendszergazdák mindegyikre folyamatosan odafigyelni.

A jó rendszereket elsősorban nem kívülről figyelik („polling”), hanem azok saját magukat figyelik belülről, és riasztanak minket, ha baj van. Erre még nincs egységes szóhasználat, de gyakran „Server Generated Alert System” a neve.

Oracle esetén ez külön fizetős opció, és mindenféle automatával van teletűzdelve az adatbáziskezelő rendszer.

Az Oracle C-ben íródott, ami ma már inkább rossz tulajdonság, mint jó, és a kód jelentős része igen „dohos”. Ezt próbálják ellensúlyozni azzal, hogy rengetegen fejlesztik. (Jobb lett volna, ha Java-ban fejlesztik ki, de ezen már késő bánkódni).

Úgy tűnik, hogy sajnos elkerülhetetlenek, bug-ok minden adatbázis kezelő rendszerben vannak, még a legjobbakban is.

A megoldási módszer is lényeges, hiszen érzékeny adatokat tárolunk. Ki férhet hozzá a hiba felderítése során? Nem szerencsés, ha a megoldáshoz el kellene küldenem a gyártónak a teljes adatbázist, hiszen értékes adatokat tárolok benne.

Jellemzően nemcsak a hibajavításokat, hanem az új verziókat is fedi a support-díj .