Az 5 leggyakoribb adatbázis-fejlesztési hiba

Rosszul kivitelezett alkalmazások, rendszerek esetén a legtöbbször a forráskódban található bugokról, helytelenül felépített, és/vagy használt metódusokról hallunk, pedig sok esetben már jóval korábban, a relációs adatbázis tervezésekor is elkövetünk súlyos hibákat. Jelen posztunkban ezek közül mutatjuk meg nektek az 5 leggyakoribbat.

1. Az elsődleges kulcsok helytelen megközelítése/használata

Az elsődleges kulcsokat számtalanszor arra, vagy úgy használják, amire, vagy ahogy nem kellene őket. Fontos leszögeznünk ugyanis, hogy egy sor elsődleges kulcsának logikailag teljesen el kell különülnie az üzleti adatoktól. Ettől függetlenül természetesen alkalmazhatunk bizonyos, egyediségre vonatkozó megszorításokat egy-egy mezőcsoportra nézve, de ez teljesen más téma. Az elsődleges kulcsokat nem szabad jelentéssel bíró adatok bármilyen kombinációjából előállítani, azoknak célszerű az adatbázis által szekvenciálisan generált értékeknek lenniük, melyek egy adott sor beszúrása után csak indokolt esetben módosulhatnak.

2. Helytelen normalizálás

Amikor az adatok rendszerezéséhez, a különböző entitások definiálásához ér egy informatikai projekt, akkor hajlamosak az illetékesek végletekben gondolkodni: van olyan, aki mindenhol relációkat lát, és van, aki sehol sem. Természetesen ebben az esetben is az arany középút a megoldás:

• Ha egy tábla egy bizonyos oszlopában az értékek változatossága alacsony (itt most nyilván nem numerikus adatokat tároló mezőkre gondolunk), és egy adott érték módosítása nem csak az adott sorra van kihatással, hanem az egész táblára, akkor ezeknek az értékeknek bizony egy külön táblában van a helyük. Egyszerű, gyakori példa: a felhasználók országát nem érdemes egy szöveges mezőben tárolni, sokkal jobb, ha erre az információra törzsadatként tekintünk, és egy külön táblában tároljuk az országokat, melyekre máshonnan is hivatkozhatunk.
• Amennyiben - hasonlóan az előző ponthoz - bizonyos értékek több sor ugyanazon oszlopában is felbukkannak, de egyetlen mező módosítása nem érinti a többi, vele megegyező értékű mező sorát, akkor ezeket az adatokat nem célszerű másik táblába mozgatnunk.

3. Tárolt eljárások túlzott alkalmazása

A modern, ORM alapú megoldások elterjedésével egyre kevesebb helyen indokolt a tárolt eljárások használata. Szó se róla, rengeteg esetben még mindig sokkal előnyösebb a használatuk más alternatíváknál, de mindenképp érdemes megfontolni, hogy mire, mikor, és miért alkalmazzuk őket.
A legfontosabb ellenérv velük szemben talán az, hogy nehezen karbantarthatóak. Gondoljunk csak bele, milyen nehéz meghatározni, hogy pontosan mi, és mikor "használja" őket! Ebből aztán egyenes ágon következik, hogy ha valamelyiket módosítanunk kellene, akkor elővigyázatosságból inkább egy másolatot készítünk belőle, ami csak tovább bonyolítja a problémákat a későbbiekben.

4. Elsődleges kulcsok hiánya

Ez az eset abban tér el az első ponttól, hogy ott legalább létezik elsődleges kulcs, még ha rosszul is képzett. Ennek ellenére - bármilyen meglepő - számtalanszor előfordul, hogy egy táblának egyszerűen nincs elsődleges kulcsa. "Beleteszem a joinba ezt a 4 oszlopot, és tuti, hogy egyedi lesz!" Aztán persze az élesítés után legkésőbb pár héttel kiderül, hogy nem működik a dolog, mert mégsem garantálja a szóban forgó 4 oszlop a sorok egyediségét.

5. "Hard delete"

Természetesen vannak olyan esetek, amikor indokolt bizonyos rekordok végleges törlése, de nagyon sokszor csak lustaságból nem élnek a soft delete lehetőségével a fejlesztők, vagy a tervezők. Egy rekord végleges törlése rengeteg fáradtságot okozhat, ha később a logokat bújva kell kinyomoznunk, hogy mi, honnan, és miért törlődött ki. Ezzel szemben, ha az alkalmazásunk szűri ki az üzleti szempontból inaktívnak jelölt rekordokat, akkor egy sokkal rugalmasabb megoldáshoz jutunk.

Ti milyen hasonló hibákkal találkoztatok a munkátok során?