Categorias: Todos - költségek

por Zsolt Vajda 7 anos atrás

237

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

Az adatbázis-kezelő kiválasztása során számos tényezőt kell figyelembe venni, beleértve az árakat és a teljesítményt. Az ingyenes rendszerek általában nagyobb kockázatot hordoznak az adatvesztés és az alacsonyabb rendelkezésre állás miatt.

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

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

El kell döntenünk, hogy ingyenes vagy fizetős adatbázis kezelőt választunk, ha fizetőset, akkor melyiket, melyek azok a lehetőségek, amelyek mindegyik adatbázis kezelőben benne vannak, és hol vannak esetleg azok a pluszok, amelyek miatt a fizetős rendszerek többet nyújtanának. Ingyenes esetén nagyobb a kockázata annak, hogy adatokat veszítsünk, kisebb legyen a rendelkezésre állás. Fontos megjegyezni, hogy az ingyenes adatbázis kezelő rendszerek esetében is van költség.. Magasabb árú adatbázis kezelő rendszer esetén jobbak a lehetőségeink, rendelkezésünkre állhatnak luxus lehetőségek.


Az embereknek eleinte általában a szoftver árának és a performanciának (működési sebességnek) a megnézése jut eszébe először, ezek közül az ár valóban meghatározó elem, a performancia kevésbé, az egyes adatbázis kezelő rendszerek működési sebességének összehasonlítására léteznek ugyan módszerek, de ez egy összetettebb kérdés, nem igazán lehet egyértelműen igazságot tenni. 


Az adatbázis kezelő kiválasztása az esetek többségében évtizedes következményekkel jár, ugyanis nem cserélgethetjük kis időközönként a cégünk által használt adatbázis kezelő rendszereket.


A döntés személyzeti kérdéseket is befolyásolja, hiszen a választott adatbázis kezelőhöz értő szakembereket kell alkalmazni.


A kérdés fontosságát mutatja, hogy az informatikára költött pénzek nagy részét gyakran az adatbázis kezelőre fordítják. Ez azonban nem mindig igaz, például abban az esetben, ha egy bank egy „kulcsrakész” SAP rendszert vezet be, akkor az Oracle adatbázis licenszek költsége jóval kisebb lesz az SAP rendszer költségeihez képest. Amennyiben nem kulcsrakész szoftvert veszünk, hanem házon belüli fejlesztés céljából szerzünk be adatbázis kezelő rendszert, akkor biztos, hogy egy nagyságrenddel nagyobb összeget költünk adatbázis kezelő rendszerre, mint például hardverre.


Ahol nincs külön forrás megjelölve, ott az előadás diái és az előadáson elhangzottak alapján dolgoztam.

Azok a képességek, amelyekkel mindegyik relációs adatbáziskezelőnek rendelkeznie kell

Optimalizáló (automatikus végrehajtási terv generátor)
Adatszótár
Kényszerek
ACID képességek:
Tartósság (Durability)
Izoláció (Isolation)
Konzisztencia (Consistency)
Atomi tranzakciók (Atomicity)
Tranzakciókezelés
SQL nyelv: DDL, DML, Query
Táblák, nézetek

A gyártó tulajdonságai

A szoftvertámogatás minősége
A támogatás nemcsak a téves kódra, hanem a téves használatra is kiterjed-e vajon, tehát segítenek-e a felhasználónak akkor is, ha ő hibázott, nem a szoftver volt rossz?
„Bugs are facts of life”

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

A „support” általában borsos áron történik

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

Hányan és hány problémát oldanak meg a termék gyártójánál? A mi problémánkat jellemzően megoldják-e és ha igen, mennyi idő alatt?

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.

Ha már vannak hibák, kritikus kérdés, hogy van-e aki javítsa őket?

A szoftver fejlődésének a képessége és üteme
Fontos kérdés, hogy milyen programozási nyelvet használtak az adatbázis kezelő rendszer gyártói

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).

Másik probléma lehet, ha a kód már ősrégi, és most már csak nehezen karbantartható
Egyes szoftverek nagyon gyenge lábakra épültek, és ezért nem tudnak továbbfejlődni
Azt a szoftvert el kell kerülni, amelynek a gyártója nem fejleszti azt nagy tempóban
Az igények folyamatosan bővülnek és változnak

Monitorozás

Automatikus monitorozás és hangolás

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.

Automatikus monitorozás

Az igazán jó rendszerek nemcsak riasztanak, hanem megoldást is javasolnak, sőt esetleg a javasolt változtatást meg is teszik automatikusan.

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

A jó rendszerek saját magukat figyelik belülről

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.

Nő a „monitoring”, mint tevékenységi kör jelentősége
Szakember általi monitorozás, hangolás lehetősége

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.

Nagyon fontos, hogy ez a monitorozhatóság SELECT utasításokkal történjen

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

A mentések sokszínűsége

Lényeges, hogy mások eszközeivel (módszereivel) is lehessen adatbázist menteni.
Fontos, hogy lemezre és szalagos mentőegységre is lehessen menteni
A mentési katalógus is nagyon hasznos
A mentés elvégezhető legyen online

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

Teljes és inkrementális mentésre is legyen lehetőség

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

Hatékony mentési módszerre van szükség

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

A jó adatbázis kezelő rendszernek saját mentési programja kell, hogy legyen

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.


Biztonság

A használat auditálása

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.

Fontos, hogy az auditálásnak legyen értelme

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

Hatékony elemzési lehetőségek kellenek az „Audit Record”-ok felett.
Konfigurálhatóság

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.

Mennyire védettek az adatok a DBA-tól
Ha félünk a DBA-k és az operációs rendszerek rendszergazdáinak a jogosultságaitól, akkor vajon létezik-e olyan szoftververzió, ahol a DBA és a rendszergazda sem férhetnek hozzá az adatokhoz

Az Oracle adatbázis esetén ezt a megoldást Oracle Database Vaultnak nevezzük.

Egy komoly és eldöntendő kérdés, hogy veszélyforrásként tekint-e a cég a rendszergazdákra, vagy nem
Feltörési lehetőségek, adatlopások
Csupán „Denial-Of-Service” típusú sérülékenységekről beszélnek, vagy komoly adatlopások, adatmódosítások is történhetnek (pl. „SQL Injection”)?
Megtesz-e a gyártó eleget ahhoz, hogy megelőzze az újabb sebezhetőségek kialakulását?
Hogyan reagál a szoftvergyártó, ha kiderül 1-1 sebezhetőség? Milyen gyorsan oldják meg a problémát?
Mégis érdemes felmérni a választás előtt, hogy az adott szoftvert milyen gyakran törik fel? Hány incidens került nyilvánosságra az elmúlt években?
Nem létezik 100%-os biztonság
Minden adatlopás egy tragédia. Sok esetben a következmény a cég megszűnése.
Adatok titkosítása

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

Hatékonyság

Magas rendelkezésre állás

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.

Problémás szoftverfrisítések

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.

RAC opció

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

Állásidő

Nem betervezett (valamilyen hiba miatt)

Betervezett (előre bejelentett)

Skálázhatóság

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 .

RAC

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

Lineáris skálázhatóság

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.

Performancia (gyors működé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 új verzió szinte mindig lassabb az előzőnél

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.

Performancia versenyek

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.

Helyreállíthatóság

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.

Katasztrófatűrés

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.

DataGuard

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

Távoli adatbázis-másolatok

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.

Nem létezik teljesen biztos megoldás

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.

Mindere gondolni kell

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.

Könnyű feladat legyen

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

A helyreállítás ideje

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.

Mentési mechanizmus

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”).

Az SQL-en túl

Milyen segédeszközök léteznek
Például Oracle esetén ezek az eszközök a következőek:

Oracle Data Pump

SQL*Loader

A gyakorlatban felmerül az igény különböző nem-SQL feladatok egyszerű és hatékony elvégzésére, például:

Adatok igény szerinti áthordozása adatbázistáblákból bináris állományokba és később ezek visszatöltése ugyanabba, vagy másik adatbázisba

Adatok betöltése az adatbázistáblákba

XML állományokból

Excell táblákból

CSV („Comma Separated Values”) fájlokból

szöveges fix formátumú állományokból

A funkcionalitás kiterjesztése SQL-en túlra

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.

Közösségi fejlesztések

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.

Gyártó is biztosíthatja

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.

Adatbázis triggerek

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

A triggerek feltételezik azt, hogy a procedurális nyelv már rendelkezésre áll
Nemcsak DML triggerek léteznek

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.

DELETE és UPDATE esetére is hasznosak a triggerek

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

Post-INSERT triggerek

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

Pre-INSERT triggerek

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

Procedurális lehetőségek

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.

Java

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

PL/SQL

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

Algoritmusok

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

Így kiterjeszthető az adatbázis kezelő rendszer funkcionalitása

A kényszerek halmaza is kibővíthető így

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.

A felhasználó kifejlesztheti a saját kiterjesztéseit

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.

Maga a gyártó is fejleszthet ilyen kiterjesztéseket

Így a feldolgozás az adatok „közelében” történhet

Karakterkészlet

A jó adatbázis kezelő rendszerben nem nő számottevően a helyigény a Unicode miatt (tehát UTF-8 választható)
A jó adatbázis kezelő rendszerben lehetséges a kódkonverzió az egyéb (régi) karakterkészletekről Unicode-ra
A jó adatbázis kezelőben ez a konverzió állásidő nélkül vagy rövid állásidővel elvégezhető.
Kódolás
UTF-16

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

UCS-2

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

UTF-8

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.

Unicode

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).

Saját gépterem, vagy felhő

Platform as a Service

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.

Fontos, hogy minél több dolgot támogasson

Adattípusok széleskörű támogatása

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.

Új objektumtípusok és objektumok tárolása (attribútumokkal és metódusokkal)
User Defined Data Type

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

XMLType

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.

Hardver és operációs rendszer támogatása
Embedded Database

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.

Mobile Database

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.

A későbbi platformváltások könnyűek kell, hogy legyenek

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.

A szoftver "mobilitása"

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.

Előny, ha működik Windows, Linux, Solaris, AIX, HP-UX, esetleg VMS operációs rendszereken is.

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.)

Támogatja a virtualizációt

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 jó adatbázis kezelő nem csak egy hardveren fut

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

A támogatott programozási nyelvek
Beágyazott SQL

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

PHP támogatás is előny
Microsoft: C, C#, .NET támogatás szinte kötelező
Java nyelvhez: JDBC

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

A jó adatbázis kezelő rendszernek minél több nyelvet kell támogatnia

Szabványok betartása

A relációs adatbázisok de-facto szabványa az SQL

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.

Ezen belül is előny, ha minél inkább betartja a gyártó az SQL szabvány részleteit is

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).

Megbízhatóság

Elosztott tranzakciókezelés

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.

Szükséges a megbízható tranzakciókezelés egy adatbázis kezelő rendszer és egy másik szoftver között.

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).

XA protokoll

Rendszerint XA protokollon közlekednek az adatok.

A két adatbázis közötti kommunikáció

Két különböző gyártó rendszere között

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.

XA tranzakciók támogatása

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.

Két azonos adatbázis kezelő rendszer közötti megbízható adatátvitel

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.

Elterjedtség

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.

A jó adatbázis kezelőt rajtunk kívül sokan használják a környezetünkben

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.

Kiforrottság, megbízhatóság
„Olyan az adatbázis kezelő, mint a jó bor: minél öregebb, annál jobb”
Ha bármi kételyünk van, az interneten találunk róla valamit

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.

A jó szoftver az, amelyet már mások is alkalmaztak ugyanolyan célokra, ugyanolyan körülmények között

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.

Minden szoftver bug-os

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.

Az adatbázis kezelő rendszer költsége

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.

TCO mutató

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

Az üzemeltető személyzet költségei

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.

A szükséges hardver költsége

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.

Tervezett vagy tervezetlen állásidőből fakadó üzleti károk

É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.

Esetleges adatvesztésből fakadó károk

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.

Saját gépeken való használat licenszdíja, vagy felhőből bérelt szolgáltatás bérleti díja
Support díj

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

Licenszdíj

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.