Hogyan válasszuk ki a számunkra legmegfelelőbb adatbázis-kezelő rendszert?

Licence-költség alatt alapvetően a szoftver használati jogának megvásárlását értjük. Ez általában nem örök érvényű, időközönként meg kell hosszabbítani (nagyjából évente). Ezen kívül pedig léteznek olyan licencek, amelyek engedélyezik, hogy saját szerveren is használhassuk a programot (ezt nyilván ki lehet váltani PaaS szolgáltatással).

Főleg az OLTP rendszereinknél elengedhetetlen az azonnali, gyors reakcíó egy-egy meghibásodás esetén. Erre a ad megfelelő megoldást a szoftver mellé vásárolt support szolgáltatás.

PaaS vagyis Platform-as-a-Service, annyit jelent, hogy egy felhő szolgáltató biztosítja a megfelelő infrastruktúrát, valamint magát a szoftvert is, magas skálázhatósági szinten. A szélsőséges körülményektől ( katasztrófák) abszolút óvja az programunkat és gyors a hibaelhárítás is.

A költségeket nagyban befolyásolja az, hogy mennyien használják a szoftvert, hiszen nagy felhasználás esetén komolyabb hardver szükséges a szoftver mögé a zavartalan működés érdekében.

Értékes munkaerőnek számít valaki, ha ért az adatbáziskezelő rendszerek operatív használatához. Ha valaki nem írt hozzá, akkor komoly összegeket ki lehet csengetni a különböző SQL képzésekért.

Egy 2016-os felmérés alapján egy adatbázis fejlesztő kezdő átlagbére is 500ezer és 600ezer forint között mozog.(forrás: https://www.hwsw.hu/hirek/56134/hays-salary-guide-it-informatika-fizetes-berek.html )

Ez lehet a legnagyobb költség abban az esetben, ha komolyabb meghibásodás következik be.

Főleg az OLTP rendszereket kezelő szoftverek esetében káros, akár 1 percnyi leállás is. Nem szerencsés, ha az ügyfelek nem érik el néhány percre a weboldalunkat és ezért más cégnél vásárolnak inkább.

Az adatvesztés elleni védekezésben az egyik legfontosabb elem a szoftverünk helyreállíthatósága, hiszen emberi mulasztás ( pl. rossz lemezt cserél ki a rendszergazda) és külső tényező ( pl. diszk meghibásodás) is indukálhatja néhány adatunk elvesztését. Ez pedig kockáztathatja a cég hírnevét, vagy közvetlenül is anyagi károkat okozhat.

Ha tehetjük olyan adatbázis-kezelő rendszert válasszunk, amely nem csak a régebbi mentést, hanem a legfrissebb állapotot is vissza tudja állítani.(forrás: előadás diái)

Az adatvesztésből fakadó üzleti károk rendkívül nagy kockázatot jelentenek egy vállalat számára. Ezek egy esetleges katasztrófahelyzet kialakulásával megnőhetnek. Nem érdemes saját szervertermet létrehozni, hiszen erre kiváló megoldást nyújtanak a különböző adatparkok.Pl.: Ha egész Budapesten nincs áram, a T-Systems adatparkban akkor is 3 napig biztosítani tudják a folyamatos áramellátást a szerverünknek, és a rajta futó adatbázis-kezelőnek. (Saját példa).

Az adatbázisok DBA-i elvileg az adatbázisban tárolt összes adathoz hozzáférhetnek. Jó ha erre létezik megoldása az adatbáziskezelő szoftvernek. Pl.: Oracle: Database Vault (2530 USD a szoftver licensz és a hozzátartozó support igénylése.)Forrás: http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf

Nincs 100%-ig biztos tűzfal az adatbázisunk védelmére, viszont ügyelni kell a 100%-hoz konvergáló adatvédelemre. Ehhez különböző megoldások léteznek.Pl.: titkosítás: Az adatokat csak SQL utasítással lehet dekódolni (insert kódol, select dekódol) (Forrás: előadás diái)

Kiforrottság alatt az adatbáziskezelő rendszer kezdeti hibáinak kiküszöbölését lehet érteni. Nyilván, minél régebb óta dolgoznak rajta, annál több hibáját kezelték már. Ezért általában minél idősebb egy adatbáziskezelő rendszer, annál megbízhatóbb.(Forrás: előadás diái)

Minél elterjedtebb egy szoftver, annál könnyebb "sorstársakat" találni egyes hibák megoldásához. Többen értenek hozzá, több forrás van róla akár az interneten is és emiatt gyorsabb a problémamegoldás.(Forrás: előadás diái)

Minél több programozási nyelvet támogat az adatbázis-kezelő rendszerünk, annál kevesebbet kell költenünk informatikusaink képzésére. C, C#, .NET támogatása szinte kötelező.

Éedemes olyan rendszert választani, amely tartalmazza azokat az adat-típusokat, amelyeket a vállalatunk üzleti tevékenysége során használna.

Alapvető követelmény, hogy támogassa az UNICODE karaktereket és lehetőleg az UTF-8 -at, vagy az UTF-16-oz. Ezen kívül nem hátrány, ha a kódkonverziót nagy átállási idő nélkül támogatja.

Ha szükséges, olyan szoftvert válasszunk, amely képes két különböző rendszer között is tranzakciókat végrehajtani.

Szükség lehet olyan algoritmusokra, amely SQL nyelven nem oldható meg megfelelően.

A triggerek azokban az esetekben hasznosak, amikor kényszerekkel nem kifejezhető szabályt szeretnénk létrehozni. Ezeket olyan procedurális nyelvekkel írhatjuk meg, amelyet engedélyez az adatbázis-kezelőnk. Pl .ilyen az,hogy adatbevitelkor a WORKERS tábla START_DATE oszlopa nem lehet múltbeli dátum, tehát tehát a pillanatnyi dátumnál kisebbkisebb kisebb . (forrás: 8. előadás diái)

Az SQL-en túlmutató igények kielégítésére alkalmas.Pl.: Regisztrációt megerősítő e-mail kiküldése.

Egy adatbázis gyorsasága több fázisban is növelhető. Egyrészt minél erősebb hardver dolgozik alatta, annál gyorsabb lesz, másrészt viszont maga a szoftver is okozhat gyorsulást. Megtévesztő lehet azonban egy gyors szoftver, hiszen a gyorsaság gyakran a "minőség" rovására mehet. (Forrás: előadás diái)

Legjobb esetben egy szoftver a rendelkezésekre álló erőforrásokból csak annyit használ fel, amennyire ténylegesen szüksége van. A skálázhatóságnak az lenne a lényege, hogy a rendelkezésre álló erőforrásokat mindig a szükséges erőforráshoz igazítsa.Forrás: előadás diái)

AZ adatbázisunk auditálásának az a lényege, hogy pontosan tudjuk mikor, melyik felhasználó milyen utasításokat hajtott végre. Ezt ugyan úgy SQL utasításokkal érjük el. Az a legjobb eset,ha tudjuk ezeket automatizálni.(Forrás: előadás diái)(a videón 1:30 -nál kezdődik egy auditálási példa Access-ben )

A monitorozás lényege megtalálni a szűk keresztmetszetet, azaz a szoftver azon pontját, ami miatt lassabbak a lekérdezéseink.