MySQL adatbázis tervezése webalkalmazásokhoz

Amikor három munkatárs reggel párhuzamosan könyvel árut, egy ügyfél ellenőrzi a szállítási státuszt, és a back office számlát állít ki, egy alkalmazás minősége nem a designjában mutatkozik meg. Abban mutatkozik meg, hogy mindenki pontosan ugyanazt, helyes adatállapotot látja-e. A MySQL adatbázis tervezése egy webalkalmazáshoz ezért nem azt jelenti, hogy táblákat hozunk létre a lehető leggyorsabban. Azt jelenti, hogy elég pontosan megértjük a valódi munkafolyamatokat ahhoz, hogy biztosítsuk: az adatok terhelés alatt, hibák során, és a vállalkozás növekedésével is megbízhatók maradnak.

Különösen belső platformoknál, raktári és rendelési folyamatoknál, vagy ügyfélportáloknál az adatbázist gyakran túl későn kezelik. Először felépítik a felületet, aztán mezőket adnak hozzá, majd kivételeket. Ez működik egy prototípusnál. Az üzemeltetésben ez duplikált adatkészletekhez, homályos állapotokhoz, és olyan jelentésekhez vezet, amelyekben már senki sem bízik teljesen.

MySQL adatbázis tervezése webalkalmazásokhoz: kezdje a munkafolyamattal

Az első vázlatnak nem oszlopnevekkel kellene kezdődnie, hanem egy konkrét munkahelyzettel. Vegyünk egy árubeérkezést: egy szállítmány megérkezik, hozzárendelik egy beszállítóhoz és egy rendeléshez, ellenőrzik a mennyiségeket, hozzárendelnek egy tárolóhelyet, és a készlet változik. Az üzemeltetéstől függően ez a folyamat kiegészítőleg fényképeket, minőségi ellenőrzést, felfüggesztési státuszt, vagy nyomon követhető javítást igényel. Ebből a munkafolyamatból bontakoznak ki a funkcionális objektumok. Tipikus példák a tételek, beszállítók, rendelések, pozíciók, tárolóhelyek, készletmozgások, és felhasználók.

Az objektum és az esemény közötti megkülönböztetés döntő. Egy tétel leírja, hogy micsoda valami. Egy készletmozgás dokumentálja, hogy egy mennyiség egy adott helyen egy adott időpontban megváltozott. Mindkettő keverése egyetlen táblában gyorsan a nyomon követhetőség elvesztéséhez vezet.

Néhány nehéz kérdés segít minden objektumnál: mi az egyedi identitás? Mely információ változhat? Ki változtathatja meg? Mely adatokat kell történelmileg megőrizni? És milyen szabályok érvényesek, amikor két ember egyszerre dolgozik? Ezek a kérdések jobban megakadályozzák a későbbi improvizációt, mint egy hosszú lista állítólag teljes adatbázis-mezőkről.

Az adatmodellnek szabályokat kell kifejeznie

Egy adatbázis nem pusztán tárhely az űrlapbevitelekhez. Magának kellene kikényszerítenie a központi szabályokat. Ha minden készletmozgásnak pontosan egy tételhez és egy tárolóhelyhez kell tartoznia, az idegen kulcsok a modellbe tartoznak. Ha egy külső rendelésszám csak egyszer fordulhat elő bérlőnként, egyedi index szükséges. Ha egy pozíció sohasem létezhet fejrendelés nélkül, ezt a kapcsolatot egyértelműen modellezni kell.

A MySQL 8 InnoDB-vel robusztus alapokat biztosít ehhez: tranzakciók, idegen kulcsok, zárolási mechanizmusok, és konzisztens változtatások több táblán keresztül. Egy mozgás, aktuális készlet, és ellenőrzési napló írásakor egy árubeérkezési könyvelés során ennek egységes tranzakcióként kellene történnie. Ha egy lépés meghiúsul, nem maradhat félig befejezett művelet.

Azonban nem minden szabály tartozik az adatbázisba. A jóváhagyások, összetett árazási logika, vagy szerepkör-függő folyamatlépések gyakran jobban helyezhetők el az alkalmazáslogikában, mert funkcionálisan gyorsabban változnak. A határ pragmatikus: azokat a szabályokat, amelyek megsértése tartósan károsítja az adatokat, az adatokhoz a lehető legközelebb kell biztosítani. Azok a szabályok, amelyek gyakran változnak vagy erősen kontextusfüggők, jól tesztelt alkalmazáskódot igényelnek.

Ne keverje össze az előzményeket az aktuális értékekkel

Gyakori hiba csak az aktuális készletet vagy aktuális státuszt tárolni. Ez addig elegendő, amíg valaki meg nem kérdezi, miért változott a mennyiség tegnap, vagy ki állította vissza a rendelést. Üzemeltetési rendszereknél egy mozgás- vagy eseménytörténet gyakran értékesebb, mint egyetlen felülírható mező.

Ez nem jelenti minden kattintásmozgás tartós naplózását. Az üzletileg releváns változtatásokat kellene naplózni: státuszváltozásokat, mennyiségmódosításokat, javításokat, jóváhagyásokat, és hozzárendeléseket. Egy jó audit bejegyzés tartalmaz egy időbélyeget, felhasználót vagy rendszerfolyamatot, korábbi és új értéket, és érthető indoklást, amikor a munkafolyamat ezt megköveteli. Ez lehetővé teszi a hibák tisztázását anélkül, hogy e-maileket, papírlistákat, vagy adatbázis-mentéseket kellene átkutatni.

Tudatosan válassza a kulcsokat, adattípusokat, és elnevezési konvenciókat

A technikai döntések kicsinek tűnnek, de évekig alakítják a karbantartást és integrációkat. A belső elsődleges kulcsokhoz az automatikus hozzárendeléssel rendelkező BIGINT értékek gyakran józan, könnyen kezelhető választás. A UUID-k akkor lehetnek ésszerűek, amikor az adatok offline keletkeznek, több rendszer ír függetlenül, vagy a külső felületeknek nem szabadna szekvenciális ID-kat felfednie. Azonban több tárhelybe kerülnek, és valamivel több figyelmet igényelnek az indexeknél és rendezésnél.

A pénzösszegeket DECIMAL-ként kell tárolni, nem FLOAT-ként vagy DOUBLE-ként. A mennyiségeknek is funkcionálisan megfelelő pontosságra van szükségük: a tételszámok gyakran egész számok, míg a súlyok és hosszúságok nem. Az időbélyegeket egységesen kellene kezelni, ideális esetben belsőleg UTC-ben, miközben a felület az üzemeltetés helyi időzónáját jeleníti meg. Különösen műszakváltásoknál és nyári időszámításnál ez megakadályozza a nehezen megtalálható eltéréseket.

A neveknek is unalmasnak és egyértelműnek kellene lenniük. Az order_items vagy inventory_movements hasznosabb, mint kreatív rövidítések, amelyeket csak az eredeti projektcsapat ért. A konzisztens egyes vagy többes formák kevésbé fontosak, mint a konzisztencia. Ugyanolyan ésszerűek az olyan mezők, mint a created_at, updated_at, és, ha szükséges, a deleted_at. A soft delete mindazonáltal nem szabványos kötelezettség. Jogilag vagy üzemeltetésileg releváns rekordoknál egy tiszta sztornózás általában jobb, mint egy láthatatlanul törölt adatkészlet.

Az indexek a tényleges lekérdezéseket követik, nem a találgatást

Egy index masszívan felgyorsíthat egy keresést, de bonyolultabbá teszi az írási műveleteket és tárhelyet fogyaszt. Ezért „egy index minden mezőn" nem stratégia. A legfontosabb lekérdezéseket korán kellene meghatározni: egy ügyfél nyitott rendelései, egy tétel mozgásai egy időszakon belül, készlet tárolóhelyenként, vagy nemrég módosított rekordok egy felülethez.

Az összetett indexek sorrendje itt számít. Ha az alkalmazás rendszeresen keres tenant_id, status, és created_at szerint, egy összetett index pontosan ebben a sorrendben gyakran ésszerű. Hogy tényleg illeszkedik-e, azt a végrehajtási terv mutatja meg az EXPLAIN segítségével, nem a megérzés. Az adatbázisokat nem látványos trükkök teszik gyorssá, hanem megfigyelhető lekérdezések, illeszkedő indexek, és realisztikusan tesztelt adatmennyiségek.

Növekvő táblákhoz egyértelmű megőrzési stratégia éri meg. Kell-e a technikai naplóknak öt évig a fő produkciós adatbázisban ülniük? Nem feltétlenül. Az üzleti rekordok, mozgások, és ellenőrzési igazolások más megőrzési időszakokat igényelnek, mint a hibakeresési információk. Az archiválás nem egy gyenge rendszer jele, hanem egy megfontolt üzemeltetési döntés.

A többfelhasználós működés tranzakciókat és egyértelmű állapotokat igényel

Egy webalkalmazásban több kérés fér hozzá egyszerre ugyanazokhoz az adatokhoz. Ez normális a napi raktári üzemeltetésben, nem kivétel. Két munkatárs könyvelheti ugyanazt a készletet, miközben egy import új rendeléseket hoz létre. Tranzakciók és célzott zárolás nélkül fennáll az elveszett módosítások vagy negatív készletek kockázata, amelyek csak hetekkel később válnak nyilvánvalóvá.

Kritikus műveleteknél egyértelműnek kellene lennie, mely adatokat olvasnak és írnak egy tranzakción belül. Néha egy atomi frissítés elegendő, mint például egy készlet, amely csak akkor változik, ha az elérhető mennyiség elegendő. Más esetekben egy sorzár ésszerű, hogy egy művelet kontrollált módon ellenőrizhesse az adatállapotot, és utána módosíthassa. A hosszú tranzakciók viszont problémásak: blokkolják a más munkát, és növelik a konfliktusok kockázatát.

Ugyanolyan fontos a funkcionális állapotok korlátozott halmaza. Egy rendelés nem lehet egyszerre „nyitott", „részlegesen szállított", és „kézzel feldolgozott" ellentmondó mezők karbantartása miatt. A meghatározott státuszátmenetek egyszerűbbé teszik a felületeket, jelentéseket, és automatizálásokat. A kivételek megengedhetők, de meg kell nevezni és dokumentálni kell őket.

Tervezze meg a biztonságot, bérlőket, és üzemeltetést a kezdetektől

Az alkalmazásnak dedikált adatbázis-felhasználót kellene használnia a MySQL-hez minimális jogosultságokkal. Az írási hozzáférés a webalkalmazáshoz nem jelenti azt, hogy ennek a felhasználónak táblákat kell törölnie vagy felhasználói jogosultságokat kell módosítania. Az adminisztratív fiókok nem tartoznak produkciós konfigurációs fájlokba, és soha egy repository-ba.

Amikor több ügyfél, telephely, vagy vállalat dolgozik egy alkalmazáson belül, a bérlő-izoláció architektúrális döntés, nem visszamenőleges szűrőfeltétel. Egy közös adatbázis tenant_id-vel hatékony és könnyen karbantartható lehet, de konzisztens ellenőrzéseket igényel minden lekérdezésben, és egyértelmű szabályokat az indexekhez. A külön adatbázisok erősebb izolációt kínálnak, mégis növelik a ráfordítást frissítéseknél, kiértékeléseknél, és üzemeltetésnél. Hogy melyik variáció illeszkedik, az adatvédelmi követelményektől, adatmennyiségtől, és üzleti modelltől függ.

A biztonsági mentések csak akkor biztonsági mentések, ha a visszaállítást teszteltük. Meghatározott ritmus szükséges a mentésekhez, megőrzéshez, és helyreállításhoz. Hasonlóképpen, a tárhely, lassú lekérdezések, és meghiúsult feladatok monitorozása, a dokumentált frissítésekkel együtt, a rendszerhez tartozik. A MySQL 8, PHP 8.4, és modern webalkalmazások jól üzemeltethetők hosszú távon, ha a függőségek, hozzáférési adatok, és telepítési lépések nem kizárólag egy fejlesztő fejében léteznek.

Ésszerű terv a produkciós első nap előtt

A megvalósítás előtt egy kompakt adatmodellnek kellene léteznie példa munkafolyamatokkal. Ez tartalmazza a kulcstáblákat és kapcsolatokat, státuszszabályokat, jogosultságokat, várt lekérdezéseket, felületeket, és egy koncepciót a mentésekhez és audit naplókhoz. Ennek a tervnek nem kell száz oldalasnak lennie. Meg kell ragadnia azokat a döntéseket, amelyek utólagos javítása később drága lenne.

A softify.pro-nál az adatbázis-tervezés ezért azokkal az emberekkel kezdődik, akik könyvelnek, ellenőriznek, komissióznak, vagy kivételeket oldanak meg. Ha egy meglévő táblázat megbízhatóan leképez egy kezelhető folyamatot, maradhat a helyes megoldás. Ha több ember dolgozik egyszerre, rekordok keletkeznek, és a hibáknak nyomon követhetőnek kell lenniük, az adatbázis ezzel szemben ugyanolyan tervezési ráfordítást érdemel, mint a felület. A legjobb architektúra végül az, amely egyszerűsíti a munkanapot, és két év múlva is átláthatóan megváltoztatható.