von Farkas Norbert Vor 7 Jahren
173
Mehr dazu
Manapság többségében relációs adatbázisokat használnak, éppen ezért számos olyan adatbázis-kezelő szoftver került piacra, melyek közül nehezen tudjuk kiválasztani a vállalatunk számára legmegfelelőbbet. A gondolat térkép a választás során felmerülő problémákat mutatja be.
Alapvetően a felmerülő problémákat négy csoportba tudtam besorolni (előélet, költségek, alkalmazkodó képesség és operatív képességek). Ezek között vannak olyan alpontok, amelyek egy, vagy több másik kategórián belüli tényezőre is hatással lehetnek.
(Forrásként alapvetően a 13.heti előadás diáit használtam.)
A monitorozás lényege megtalálni a szűk keresztmetszetet, azaz a szoftver azon pontját, ami miatt lassabbak a lekérdezéseink.
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 )
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)
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)
Szükség lehet olyan algoritmusokra, amely SQL nyelven nem oldható meg megfelelően.
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.
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)
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.
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.
Éedemes olyan rendszert választani, amely tartalmazza azokat az adat-típusokat, amelyeket a vállalatunk üzleti tevékenysége során használna.
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ő.
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)
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)
Külső veszélyforrás
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)
Belső veszélyforrás
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
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).
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)
Ez lehet a legnagyobb költség abban az esetben, ha komolyabb meghibásodás következik be.
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.
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.
É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 )
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.
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.
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.
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).
