Mi az az adatbázis? Útmutató alkalmazásokat építőknek

Az adatbázis rendezett információtár, amelybe egy alkalmazás ment, és amelyből olvas — a felhasználóit, rendeléseit, foglalásait, üzeneteit. Ellentétben azzal az információval, amelyet csak a böngészőlapon tartunk, az adatbázisban lévő adat frissítés vagy újraindítás után is megmarad, és mindenki, aki használja az alkalmazást, ugyanazokat a rekordokat látja. Az adatbázisok többsége táblákba rendezi az adatokat, hasonlóan egy táblázat lapjaihoz, de szigorú szabályokkal, amelyek megőrzik az adatok egységességét.

Miért fontos ez, ha MI-val építesz

A leggyakoribb meglepetés azoknál, akik MI-vel építenek, egy olyan alkalmazás, amely késznek látszik, de mindent elfelejt. Hozzáadsz egy ügyfelet, frissíted az oldalt, és eltűnt. Ez általában azt jelenti, hogy az alkalmazás a böngésző memóriájában tartotta az adatokat, nem adatbázisban.

Az adatbázis ad otthont sok olyan fontos döntésednek is, akár tudod, akár nem:

• Mit rögzítesz. Ha nem tárolod a foglalás állapotát, nem tudod megmutatni, mely foglalásokat mondták le.
• Hogyan kapcsolódnak a dolgok. Az, hogy egy ügyfélnek több foglalása lehet-e, vagy egy foglalásnak több szolgáltatása, az egész alkalmazást meghatározza.
• Ki mit láthat. A legtöbb adatvédelmi hiba arról szól, mely rekordokat olvashat egy felhasználó.

Nem kell magadnak megtervezned az adatbázist. De az alapok megértése segít pontosan leírni az adataidat, és korán felismerni a problémákat.

Mindennapi hasonlat

Képzelj el egy rendezett iratszekrényt egy kis irodában.

Minden fiók egyfajta dolgot tart: az egyik az ügyfeleknek, a másik a találkozóknak, a harmadik a számláknak. A fiókon belül minden mappa ugyanazt a formát követi, ugyanazokkal a kitöltött mezőkkel. Minden mappának egyedi hivatkozási száma van, és ha egy számla egy ügyfélhez tartozik, a számlamappa az ügyfél számát jegyzi fel, nem másolja le a teljes aktáját.

Ez egy relációs adatbázis. A fiókok a táblák, a mappák a sorok, a mezők az oszlopok, a hivatkozási számok az elsődleges kulcsok, a másik mappára mutató jegyzetek pedig az idegen kulcsok. Egy jó irodavezető szabályokat is érvényesít — nincs találkozó dátum nélkül, nem lehet két ügyfél azonos számmal —, ahogy egy adatbázis is.

Kidolgozott példa: egy szalon foglalási alkalmazása

Tegyük fel, hogy egy MI-t kérsz, hogy építsen egy foglalási weboldalt egy fodrászszalonnak. Egy észszerű adatbázisnak négy táblája lenne.

services

staff

customers

bookings

Nézd meg a bookings táblát. Nem másolja Lena nevét és telefonszámát minden foglalásba; csak a customer_id = 101 értéket tárolja. Ha Lena megváltoztatja a telefonszámát, az egy helyen változik meg, és minden foglalás az újat mutatja. Ez a relációs adatbázis lényege: minden tényt egyszer tárolj, és arra hivatkozz.

Ugyanez a szerkezet hasznos kérdésekre is válaszol:

• „Mely időpontok szabadok Omarnál pénteken?” — nézd meg Omar aznapi foglalásait.
• „Mennyit hoztak a festési időpontok ebben a hónapban?” — kösd össze a foglalásokat a szolgáltatásokkal, és add össze az árakat.
• „Mely ügyfelek nem foglaltak 90 napja?” — hasonlítsd össze az ügyfeleket a legutóbbi foglalásukkal.

Gyakori kifejezések magyarázata

Adatbázis-típusok

Szinte mindenhez, amit egy alapító vagy egy kisvállalkozás először épít, a relációs adatbázis a biztonságos alapértelmezés.

Hol helyezkedik el az adatbázis az alkalmazásodban

A látogatók soha nem beszélnek közvetlenül az adatbázissal. A böngészőjükben lévő oldal (a frontend) adatot kér a szervertől (a backendtől), általában API-n keresztül. A szerver ellenőrzi, ki kérdez és szabad-e neki, lekérdezi az adatbázist, és csak azt küldi vissza, amit az adott személy láthat.

Ez a közbülső lépés fontos. Ha a böngésző közvetlenül, teljes hozzáféréssel lekérdezhetné az adatbázist, bárki megnyithatná a fejlesztői eszközöket, és mindent elolvashatna.

Gyakori hibák és tévhitek

• Az adatok csak a böngészőben tartása. A böngésző tárolója (például a localStorage) egy eszközön és egy böngészőben él. Egy megjegyzett szűrőhöz jó, rendelésekhez nem.
• Minden egy táblába zsúfolása. Egyetlen „foglalások” tábla, amelyben minden sorba bemásolják az ügyfél nevét, telefonját és a szolgáltatás árát, gyorsan szétesik.
• Jelszavak szöveges tárolása. A jelszavakat hasheléssel kell tárolni, soha nem olvasható formában. Lásd mi a hitelesítés.
• Nincsenek szabályok az adatokra. Kötelező mezők és egyediségi szabályok nélkül lesznek dátum nélküli foglalásaid és duplikált ügyfeleid.
• A törlés elfelejtése. Döntsd el, hogy egy ügyfél törlésekor a foglalásai is törlődnek-e, megmaradnak-e, vagy a törlés le van tiltva.
• Éles adatokkal kísérletezés. Kockázatos változtatásokat előbb biztonságos helyen teszteld, és tarts biztonsági mentést.
• A táblázat örök adatbázisként kezelése. A táblázatok kezdésnek remekek, de nehezen bírják a sok egyidejű felhasználót és a jogosultságokat. Lásd hogyan alakíts táblázatot alkalmazássá.

Mit kérj az MI-építődtől

• „Ezt adatbázisban mentsd, ne a böngészőben. Mondd meg, mely táblákat hozod létre.”
• „Mutasd meg a sémát egyszerű táblázatként: minden tábla, az oszlopai és a kapcsolataik.”
• „Egy ügyfélnek több foglalása lehet; minden foglalásnak pontosan egy szolgáltatása és egy munkatársa van.”
• „Az ügyfél e-mailje legyen kötelező és egyedi.”
• „Akadályozd meg, hogy két foglalás átfedjen ugyanannál a munkatársnál.”
• „Csak a bejelentkezett tulajdonos láthassa az összes foglalást; az ügyfelek csak a sajátjukat. Ezt a szerveren érvényesítsd.”
• „Ha törlök egy szolgáltatást, ne töröld a múltbeli foglalásokat — inkább jelöld inaktívnak.”

Adatbázisok a Mythexen

Ha az alkalmazásodnak adatot kell mentenie, a Mythex dedikált Postgres adatbázist ad a projekthez — ezt a csetben kérheted („mentsd a várólistás regisztrációkat adatbázisba”), vagy a /database paranccsal. A kapcsolati adatokat az alkalmazásod automatikusan megkapja, az ügynök pedig létrehozza a táblákat. Az adatbázis öt perc tétlenség után elalszik, és a következő kérésre ébred; a közzétett használatot arra az időre számítják, amíg ébren volt, ugyanabból a kreditegyenlegből, mint az építést. Ingyenes és Pro csomagban is elérhető. A adatbázis-dokumentáció részletezi a tudnivalókat, az alkalmazássablonok pedig adatvezérelt kiindulópontokat adnak.

Kérdések