Adatbázis-rendszer választásának szempontjai

Az üzleti szempontok lefordítása technikaira, és azok alapján értékelés. Például egy bankban az üzleti igény az adatok titkossága, akkor ez technikai szemmel egy titkosított adattárolást jelenthet, vagy esetleg titkosított adatkapcsolatot a szerverrel. Fontos az előrelátóság: nem csak a mostani igénynek (kapacitás, funkció, stb...) kell megfelelnie a szoftvernek, hanem a jövőben is.

Nem minden hardverrel kompatibilis minden adatbázis-kezelő, az operációs rendszer ugyan a hagyományos, mindennapi programoknál elfedi a hardverbeli különbségeket, de egy adatbázis kezelőnek olyan közel kell operálnia a hardverhez, hogy az OS nem tud mindent elfedni. Vagy ha igen, akkor sokat lassíthat a teljesítményen.

Egyre nagyobb teret hódítanak a felhő alapú szolgáltatások az IT-ben, és ez alól az adatbázisok sem kivételek: egyre több felhő alapú adatbázist lehet bérelni és használni. Előnyük, hogy rugalmas árazásúak és könnyen skálázhatóak (gyakorlatilag át kell térni egy másik előfizetésre, vagy csak egy csúszkát feljebb tolni, ami növeli a kapacitásokat és az árat is). Hátrányuk, hogy adatainkat gyakorlatilag egy fekete dobozban tároljuk, nem tudjuk mi történik velük, aminek sokkal nagyobb biztonsági kockázatai vannak, mint egy géptermi szerver üzemeltetésének.Link: 10 népszerű felhő alapú adatbázis kezelő

Ide a támogatási szempontok tartoznak, akár magáról a szoftverről, akár a szoftver által támogatott képességekről van szó.

Minél elterjedtebb egy szoftver, annál több forrás, szakember áll rendelkezésünkre egy hiba fellépésekor, így annál gyorsabban lehet a javítás.

Egy adatbáziskezelő rendszernek fontos, hogy minél több nyelvet támogasson, hiszen ez több kapcsolódási pontot jelent más szoftverekhez. Legfontosabb nyelvek ilyen szempontból a Java, C#, C, PHP és egyéb beágyazott lekérdezéseket használó nyelvek (Cobol, Fortran). Más nyelveken programozóknak is segítség, ha azt is támogatja amihez ők a legjobban értenek.

Az üzleti igényből fakadóan néhány adattípusra nagyobb szükség lehet, mint a többire, így fontos azt is megvizsgálni, hogy egyáltalán milyen adattípusokat támogat, és azokat milyen hatékonysággal kezeli az adott adatbázisrendszer. Létre tud-e hozni például saját adattípust egy fejlesztő, amiben egyedi adatstruktúrát tud kialakítani?A különböző karakterkódolások támogatási igénye nagyban függ, hogy melyik országban van szükség az adatbázisra. Például az USA-ban egy olyan cégnél, ahol (tegyük fel) csak angol nevű emberek (és ezáltal angol karaktereket) adatait tároljuk, nem olyan fontos a kínai vagy thai karakterek támogatása, mint Ázsiában. Az UTF-8 karakterkódolás a legelterjedtebb, így ez tekinthető alapnak.

Szakértőknek lehetőséget biztosítani a használati adatok, erőforrás használat és egyéb adatokhoz, amelyek segítenek az adatbázis finomra hangolásán, vagy akár audit szempontjából.

Mivel minimum 5-10 évre előre kell tervezni egy adatbáziskezelő bevezetésénél, így fontos azt is megvizsgálni, hogy milyen kilátásai vannak a szoftvernek és a gyártójának/fejlesztőjének.Például egy olyan adatbázist nem érdemes bevezetni, amelyiknek a fejlesztője csődközeli állapotban van, mert nem lesz kihez forduljunk, ha valami probléma lesz. Vagy ha egy bugot fedezünk fel, nem fogja senki megírni a frissítést, ami kijavítja.

Minden adatbáziskezelő rendszer az SQL szabványt használja, azonban ettől kisebb-nagyobb mértékben el lehet térni. Ha jobban eltér a nagy könyvben megírt SQL-től, akkor ez nagyobb funkcionalitást eredményezhet ugyan, de áttéréskor nehézségeket okozhat. Az SQL szigorú betartása ellenkező hatású.

Az adatbázis kezelő szoftverek nem csak a felhasználóval kommunikálnak, hanem több másik adatbázissal is (például adatmigrálás). A több renszert érintő tranzakciót hívjuk elosztott tranzakciónak. Természetesen az SQL-ben elvárt tulajdonságok (pl. ACID) szintén teljesülniük kell ilyen tranzakciók esetén is.Két fajtája létezik: az első amikor két ugyanolyan adatbáziskezelő folytat tranzakciót. Ekkor a szoftverfejlesztők általában egy hatékony adatátviteli módszert/opciót fejlesztenek ki, amivel pl Oracle és Oracle között gyorsabb a kommunikáció.A másik típus amikor két különböző szoftvernek kell egymással kommunikálnia. Erre nemzetközi szabványok

Oracle esetén ez a "házon belüli" megoldás két adatbázis összekötésére.

Az XA protokol teszi lehetővé több, különböző típusú adatbázis kezelő közötti megosztott tranzakciókezelést.Főbb elemei az RM (Resource Manager) és a TM (Transaction Manager). Az RM felelős a megosztott erőforrások kezeléséért (megosztott tábla, objektum), például külön undo szegmenst vezet hozzá, redo log fileokat készít róla, stb... A TM menedzseli az adatokat (commit, rollback, kétfázisú tranzakció az adatok egyidőben való módosításához).

Bármilyen tökéletes is egy adatbáziskezelő rendszer, mindig lesznek benne hibák, így fel kell készülni arra az eshetőségre is, ha váratlanul leáll a szerver/OS/szoftver, meghibásodik a hardver vagy elmegy az áram. Ilyenkor fontos, hogy minél hamarabb visszaálljon a normál működésbe a rendszer. A normális időtartam helyreállításra pár perc. Esetleg helyre lehet-e állítani rögtön egy másik, távoli szerveren a működést, ahonnan folytatódna a normál működés?Ehhez lényeges a mentések nyomon követhetősége, és a sokszínű mentési lehetőségek: inkrementális, teljes mentés, van-e mentési katalógus amiből könnyen kibogarászható a visszaállítandó mentés? Milyen eszközökre lehet menteni (lemezes, szalagos, egyéb)?

Az olyan funkciók, amelyeket elvárunk egy általános adatbáziskezelőtől. Például táblák, nézetek, indexek, megkötések, stb... Ezeknek a megléte nem ad okot arra, hogy az adott szoftvert válasszuk, inkább ezek hiánya ad okot arra, hogy ne válasszuk őket.

A hatékonyság és gyorsaság is lényeges szempontok, de jellemzően a nagyobb gyorsaság a funkciók hiányával párosul, így hiába lesz gyors az adatbázis, ha nem tudja elvégezni azt, amit szeretnénk. Mivel idővel egyre több funkció kerül ezekbe a szoftverekbe, ezért jellemzően egyre nagyobbak és egyre lassabbakká válnak.

Egy trigger nem más, mint egy procedúra, amely egy megadott eseményre fut le. Például egy INSERT utasítás előtt, vagy után, vagy UPDATE előtt vagy után. Fontos szempont lehet, hogy ezeket a triggereket hogyan lehet konfigurálni, tárolni, és mennyire széleskörű eseményeket és procedúrákat lehet hozzájuk használni.

Bár nagyon sok mindenre alkalmas az SQL nyelv, de nem minden esetben lehet alkalmazni, vagy csak nagyon bonyolultan lehetne. Ez abból fakad, hogy az SQL nem procedurális, hanem deklaratív nyelv, azaz az SQL-lel nem a "hogyan?"-t definiáljuk, hanem az eredményt, a "mit?". Viszont olyan helyzetekre, amelyekre nincs előre megírt procedúra, olyankor nekünk kell definiálni a "hogyan?"-t és a "mit?" is, erre pedig a funkcionális nyelvek a legalkalmasabbak (Java, C#, stb...). Népszerű még a PL/SQL is, amely ugyan ezt a funkciót szolgálja.

A PL/SQL (Procedural Langage/Structured Query Language) gyakorlatilag az SQL procedurális megfelelője. Szintaxisa nagyban hasonlít az SQL-re, azonban itt lehet elágazásokat, változókat és ismétléseket használni.Fő jellemzője a blokkok használata: minden procedúra a 4 blokktípusból épül fel (DECLARE, BEGIN, EXCEPTION, END). A DECALREben definiáljuk a változókat, a BEGINbe írjuk magát az algoritmust, az EXCETIONbe kerülnek a kivételek, amelyek hibára vezetnek (egy "catch" blokk funkcióját tölti be más nyelvekben), és az END, amivel lezárjuk a procedúrát.Ezeket a procedúrákat le is menthetjük, és máskor is meghívhatjuk őket, akár mint egy függvényt (SUM(), COUNT(), stb...).

Az adatok titkosítása elsősorban az adatlopások megelőzését szolgálja. Ha a lemezen kódolva tároljuk az adatokat, és dekódolva olvassuk ki, akkor a lemez megszerzésével még nem tudjuk róla olvasni az adatokat.

Egy vállalatban egy adatbázis rendszer bevezetése mindig valamilyen felmerülő üzleti igény miatt kezdődik el, így ezt a célt kell szem előtt tartani minden szempont figyelembe vételekor. Ilyen módon az üzleti szempontok alá vannak rendelve a technikai szempontok.Például ha létezik egy minden szempontból tökéletes, ámde drága szoftver, de az üzleti igény nem kívánja meg a tökéletes elérhetőséget, a sok extra funkciót, a gyorsaságot, stb... (és ez a jövőben is így marad), akkor az olcsóbb, de még kielégítő megoldást kell alkalmazni.

A költségszámításkor az alábbi pontokat érdemes figyelembe venni:License költségExtra fizetős funkciókSupport díjaKiesés, adatlopásból fakadó károkSzükséges hardver költségeÜzemeltetés költségeEgy adatbázis-kezelő szoftver bevezetése általában a legnagyobb IT költségtétel, így alaposan meg kell fontolni minden szempontot.

Az üzleti felhasználásból következik, hogy mennyire fontos az elérhetősége az adatbázisnak. Természetesen az a jó, ha mindig elérhető, de például egy fél órás kiesés sokkal kevesebb kárt okoz egy olyan szerver esetében, amin naponta 15-20 utasítást végeznek, mint azon, amelyik egy közösségi médiaoldal bejegyzéseit kezeli.

Egy adatbázis-rednszerre való beruházáskor nem csak azt kell figyelembe venni, hogy most mennyire lenne kihasználva, hanem hogy 5-10 év múlva ez hogyan fog alakulni, és ehhez hogyan tud majd az adott szoftver alkalmazkodni. Ha 1-2 évente újból be kell vezetni egy új rendszert a gyors növekedésnek, az visszafogja a fejlődést, sőt, meg is állíthatja.

Nagyobb vállalatoknál fontos szempont, hogy minden alkalmazott csak azokat az adatokat láthassa és csak olyan műveletet végezhessen, amely neki engedélyezve van.Ha például az egy rendszeresen előforduló eset, hogy az alkalmazottak csak olvashatnak egy táblából, de abba nem írhatnak, és ilyen (csak olvasás) jogosultságot nem támogat a szoftver, akkor ez valószínűleg nem megfelelő választás.

Üzleti megfontolásnak kell lennie annak, hogy mennyire fontos az adatok biztonsága. Ha csak publikus adatokat szeretnénk tárolni, akkor kevésbé, de ha személyes, titkos adatokat, akkor kritikus hogy csak a megfelelő személy a megfelelő módon férhessen hozzá ezekhez az adatokhoz.Ebben nagy szerepet játszik a titkosítás, de maga a titkosító funkció fizetős lehet, nem is beszélve az adatszivárgásból eredő károkról, így az adatbiztonság szorosan kapcsolódik a költségvetéshez is.