Kapcsolt és beágyazott táblák

A relációs adatbázis-kezelő rendszerek egyik legfontosabb tulajdonsága, hogy a benne tárolt adatok között különböző kapcsolatok építhetők fel. Ennek legnagyobb előnye, hogy az adatok tárolása nem szükséges, hogy redundánsan történjen (sőt, jobb ha nem úgy történik), az egymással kapcsolatban álló rekordok hivatkozhatnak egymásra, mely növeli a karbantarthatóságot és a konzisztenciát. A hivatkozások használata egyenesen „előírásnak” számít, hiszen az első három normálforma pontosan ezen tulajdonságokat hivatott biztosítani, melyből az első a beágyazott táblaként megjelenő adatok kiszervezését írja elő külön táblába.

Itt lép a képbe az adatbázistáblák kapcsolására szolgáló „JOIN” művelet. A relációs mechanizmus matematikai háttere alapján a JOIN halmazműveleteket végez a táblák között. A legegyszerűbb az INNER JOIN mely a két tábla (halmaz) metszetét adja. A LEFT és a RIGHT OUTER JOIN a kapcsolat bal illetve jobb oldali tagjának minden rekordját illetve a két halmaz metszetét adja. Ez már így is látható, hogy meglehetősen erőforrás-igényes művelet. Tovább rontja a helyzetet, ha nincs semmilyen szűrőfeltétel a lekérésben, így minden lehetséges kapcsolást elvégez az adatbázismotor. Nyilván amikor a feltétel alapjául szolgáló mező egy külső táblában szerepel, akkor nincs más lehetőségünk, mint a kapcsolást elvégezni és az ottani mezőre megadni a szűrőfeltételt. A nagy erőforrásigény ellenére általában mégis ez a járhatóbb út. Vannak azonban kivételek.

A bejegyzés elején említettem a normálformákat. Az első normálforma az egyik legfontosabb, előírja, hogy többszörös értékeket egy mezőben ne tároljunk. Ezt csak külső táblába való kiszervezéssel lehet megoldani, a visszakeresés pedig legkönnyebben JOIN művelet használatával történhet, ami pedig – mint már arról szó volt – erőforrás-igényes művelet, ráadásul időnként kényelmetlen is. Tételezzük fel, hogy olyan adatokat kell külsőleg tárolnunk, melyek keresésére ritkán vagy egyáltalán nincs szükség, csupán legfeljebb meg kell őket valahol jeleníteni. Ilyen esetekben – bár sérti az első normálformát – érdemes elgondolkodni beágyazott „tábla” alkalmazásán.

Az elterjedtebb adatbázis-kezelő rendszerek képesek natívan kezelni XML-ként mentett adatokat. Ezt egy egyszerű függvény meghívásával – MySQL alatt ExtractValue() – a SELECT lekérés során tehetjük meg. Az említett függvény két paramétert vár, az első a lekérésben szereplő tábla XML adatokat tartalmazó mezőjének neve, a második pedig egy XPath kifejezés. Fontos, hogy a tárolt XML struktúra érvényes kell, legyen! Bővebben a MySQL dokumentációban.

Miért jó ez nekünk? Nos, az XML adatok kezelése mára meglehetősen egyszerű feladat lett, szinte bármely magas szintű programozási nyelv biztosít rá kényelmes eszközkészletet, így a tárolandó adatok XML formátumúvá alakítása a legtöbb esetben egyáltalán nem kihívás. Emellett elkerüljük a JOIN művelet használatát, mely a fentebb vázolt esetben jelentős mértékben javíthatja a teljesítményt, csökkenti a visszakeresés idejét, és összességében kényelmesebbé teszi az adatok kezelését. Ugyanakkor, ha mégis szükségünk volna egy XML struktúrában tárolt értékre való szűrésre, arról sem kell lemondanunk. Az ExtractValue() függvény ugyanis, a felolvasott értéket képes megjeleníteni és használni a lekérés eredményében származtatott mezőként, melyen akár szűrést, csoportosítást is végezhetünk – akár csak a valós mezőkön. Mivel itt külső táblás kapcsolásról nem beszélünk, az XML adatok pedig a rekordhoz kapcsolódnak, a külső táblában való keresés idejét is megspóroljuk, így ideális körülmények között az XML alapon tárolt beágyazott tábla jobb teljesítményt biztosíthat.

Természetesen ez a módszer nem helyettesítheti minden esetben a JOIN műveletet, sőt, általában inkább érdemes kerülni. Érdemes teszteket végezni, hogy kiderüljön, adott esetben melyik módszer lesz számunkra hasznosabb. Az általam végzett tesztek során termékeket, és azok tetszőleges tulajdonságait tároltam, virtuális gépes környezetben. Annak érdekében, hogy szembetűnőek legyenek a különbségek, a virtuális gép számára lecsatolt memóriát alacsonyra (512 MB) állítottam, így látható volt, mikor kezd el az operációs rendszer „szenvedni” a felolvasással és a felolvasott adatok feldolgozásával. Az eredmény meglepő volt: bár az XML alapon tárolt adatok feldolgozása némiképp hosszabb ideig tartott (100-400 ezredmásodperc, míg JOIN művelet estén legfeljebb 200 volt), az adatok mennyisége már az XML alapú tárolás számára jelentett pluszpontot. Míg XML alapon képes volt az adatbázis-kezelő 2000 „terméket” egyenként 20 egyedi tulajdonságmezővel felolvasni, addig kapcsolt táblák esetén ez a két mennyiség 1000 és 10 volt. (Megjegyzés: efölött mindkét esetben memóriatúllépés miatt megszakadt a feldolgozás – egy adatbázis szerver meglehetősen nagy étvágyú állat, mindig adjunk neki sok memóriát. :) ) Látható tehát, hogy adott esetben az XML alapú belső tábla feldolgozása kevésbé memóriaigényes, bár a feldolgozása tovább tarthat. Ugyanakkor a tesztek során minden kérésnél minden mezőt felolvastattam egyszerre, mely nem feltétlenül életszagú. Általában egy kérés során csupán néhány mező felkérésére van egyszerre szükség, mely az XML alapú tárolás esetén csupán egy újabb ExtractValue() utasítás a SELECT-ben, míg JOIN esetén bonyolult kapcsolási és szűrő feltételek megadására lehet szükség.

Hangsúlyozom, az XML alapú beágyazott táblák alkalmazásának haszna mindig a feladat függvénye, van, amikor szükségtelen, sőt kerülendő, és bár a módszer már az első normálformát is sérti (amit azért még a legkevésbé optimalizált adatbázisokban is ajánlott tartani), időnként érdemes elgondolkodni az alkalmazásán. Az éles használatbavétel előtt, sőt még a tervezés elején az igényeket is figyelembe véve érdemes méréseket, teszteket végezni, és ha a számok alapján működőképesnek tűnik, meg lehet fontolni a használatát.

Komment írásához jelentkezz be
Bejelentkezés