Az adatbázis az a réteg, amit egy vállalkozás vezetője a legritkábban lát, és mégis ez az, ami hosszú távon a legdrágábban bosszulja meg magát, ha rosszul lett megtervezve. Egy rossz adatbázis-szerkezet nem azonnal jelentkezik hibaüzenetben — hetekig, hónapokig „csak" lassú, aztán egy nap egyszerűen nem bírja a terhelést, vagy két riport két különböző számot mutat ugyanarra a kérdésre. Ez a cikk nem a technikai részletekről szól, hanem arról, mit érdemes tudnod ahhoz, hogy egy fejlesztővel érdemben tudj beszélni erről.

Az adat egyszer létezzen, ne kétszer

A legalapvetőbb tervezési szabály az, hogy minden információnak legyen egyetlen, hiteles helye. Ha az ügyfél telefonszáma egyszerre van tárolva a megrendelés táblájában és az ügyfél táblájában is, akkor előbb-utóbb eltérés keletkezik közöttük — valaki frissíti az egyiket, a másikat elfelejti, és onnantól nem tudod, melyik az igaz. Ez a jelenség, amit szakmailag adat-duplikációnak neveznek, az egyik leggyakoribb forrása annak, hogy egy rendszer idővel megbízhatatlanná válik, még akkor is, ha kezdetben tökéletesen működött.

A megoldás nem bonyolult elméletben: minden adattípusnak egy „gazdatáblája" van, és minden más, ahol ugyanarra az adatra szükség lenne, csak hivatkozik rá — nem másolja le. A gyakorlatban ez azt jelenti, hogy amikor egy fejlesztő megtervezi a rendszered adatszerkezetét, végig kell mennie azon, mely információk tartoznak logikailag együvé, és melyek azok, amik csak hivatkozásként jelennek meg máshol. Ez az a döntés, amit a legnehezebb utólag javítani — minél korábban tisztázzátok, annál kevesebb fájdalom vár rátok két év múlva.

A növekedés, amire tervezni kell — mielőtt szükség lenne rá

Egy adatbázis, amely ezer rekorddal tökéletesen működik, teljesen összeomolhat félmillió rekordnál — nem azért, mert rosszul lett megírva, hanem azért, mert a tervezés nem vette figyelembe, hogy mi történik, ha a mennyiség tízszereződik. Ennek a leggyakoribb tünete az, hogy egy lekérdezés, ami induláskor egy másodperc alatt válaszolt, fél év múlva tíz másodpercre nő — és ezzel együtt lassul az egész felhasználói élmény, mert a felhasználó minden kattintásnál erre a lassú lekérdezésre vár.

A megelőzés kulcsszava az indexelés: azoknak az adatoknak, amiket gyakran keresel vagy szűrsz (ügyfélnév, rendelésszám, dátum), a rendszernek elő kell készítenie egy gyors keresési struktúrát — olyasmi ez, mint egy könyv tárgymutatója, ami nélkül minden keresés az egész könyv végigolvasásával egyenértékű. Egy jó fejlesztő nem akkor kezd ezzel foglalkozni, amikor már lassú a rendszer, hanem a tervezés fázisában felméri, mely adatokra fognak gyakran keresni, és ezt előre beépíti.

Amit egy kkv vezetőnek tényleg tudnia kell

Nem kell adatbázis-szakértővé válnod ahhoz, hogy jó döntéseket hozz. Három dolgot azonban érdemes minden projekt elején tisztáznod a fejlesztőddel. Az első: mekkora adatmennyiséggel számolunk két-három év múlva — ez az egyetlen szám, amitől a teljes tervezési logika függ, és amit a fejlesztő nem tud kitalálni helyetted. A második: ki férhet hozzá mihez — mert az adatbázis-szerkezet és a jogosultsági rendszer szorosan összefügg, és ha ezt utólag akarod hozzáépíteni, gyakran az egész struktúrát újra kell gondolni.

A jó adatbázis-tervezés nem drágább a rossznál a projekt elején — csak akkor látszik meg a különbség, amikor a rendszer már él, és minden változtatás valódi adatokkal, valódi kockázattal jár.

A harmadik, amire kérdezz rá: mi történik hibás vagy hiányzó adat esetén — vajon a rendszer engedi-e, hogy egy rendeléshez ne tartozzon ügyfél, vagy egy számlához ne tartozzon tétel? Ezek a szabályok, amiket a szaknyelv „megszorításoknak" nevez, azok, amik megakadályozzák, hogy hibás adat egyáltalán bekerülhessen a rendszerbe — és ezek nélkül a hibák csak akkor derülnek ki, amikor már drágán kell kijavítani őket.

Ha egy meglévő rendszered kezd lassulni, vagy egy új projekt tervezésénél szeretnél biztos alapokat, beszéljünk róla — átnézzük, mire kell felkészülni.