Adatbázis hozzáadása az appodhoz (adatvesztés nélkül)

Adatbázis hozzáadásához válassz egy felügyelt relációs adatbázist (a Postgres a szokásos alapértelmezett), tartsd a kapcsolati stringet szerveroldali titokként, hozz létre egy táblát minden tárolt dologtípushoz, és a backend – soha nem a böngésző – olvassa és írja az adatbázist. Ha AI-alkalmazásépítővel dolgozol, általában elég annyit mondani: „mentsd ezt egy adatbázisba”, és az ügynök beállítja a táblákat és a kódot. A te dolgod, hogy világosan leírd az adatokat, és ellenőrizd, hogy valóban megmaradnak-e.

Ez az útmutató arról szól, mikor van szükséged adatbázisra, melyek a fő lehetőségek, hogyan írd le az adataidat, és mely hibák okoznak adatvesztést vagy adatszivárgást.

Mikor van szüksége az appodnak adatbázisra

Adatbázisra akkor van szükséged, ha az appnak emlékeznie kell valamire az oldal bezárása után, vagy adatokat kell megosztania emberek között. Tipikus jelek:

• A látogatók beküldenek valamit: űrlapot, regisztrációt, foglalást, rendelést
• A felhasználóknak saját tartalommal rendelkező fiókjuk van
• Egy adminisztrátornak látnia vagy szerkesztenie kell, amit mások hoztak létre
• Időbeli riportokat vagy számlálókat szeretnél

Adatbázisra nincs szükség olyan statikus oldalnál, ahol mindenki ugyanazt a tartalmat látja, például egy portfóliónál vagy egyszerű landing oldalnál. Ha nem vagy biztos benne, mi is az adatbázis, előbb olvasd el a mi az az adatbázis című cikket.

A lehetőségeid

Legtöbb kis- és középméretű webappnál a Postgres-típusú relációs adatbázis a helyes alapértelmezés. Jó a kapcsolatok kezelésében (egy ügyfélnek sok rendelése van), konzisztensen tartja az adatokat, és később SQL-lel kérdezhetsz rajta. Közérthető áttekintésért lásd: mi az a Postgres.

Írd le az adataidat építés előtt

A leghasznosabb, amit tehetsz, hogy leírod, milyen dolgokat tárol az appod, és hogyan kapcsolódnak. Nem kell adatbázis-zsargon. Egy foglalási appnál:

• Ügyfelek: név, e-mail, telefonszám
• Szolgáltatások: név, időtartam, ár
• Foglalások: melyik ügyfél, melyik szolgáltatás, kezdési idő, státusz (függőben, megerősítve, lemondva)

Ez három tábla. A „melyik ügyfél” és a „melyik szolgáltatás” kapcsolatokká (idegen kulcsokká) válnak a táblák között. Ezt korán érdemes helyesen eltalálni, mert a már valódi sorokat tartalmazó adatok szerkezetének megváltoztatása nehezebb, mint egy oldal elrendezésének átalakítása.

Néhány hüvelykujjszabály:

• Egy tábla minden dologtípushoz. Ne tölts rendeléseket egy szöveges oszlopba az ügyfél rekordján belül.
• Minden sornak legyen azonosítója és létrehozási ideje. Később mindkettőre szükséged lesz.
• Használj megfelelő típusokat. A dátum legyen dátum, a pénz egész centekben vagy tizedestípusban, ne szövegként.
• Jelöld kötelezőként a kötelező mezőket. Az adatbázis utasítsa el a rossz adatot, ne csak az űrlap.

Példa promptok

Egyszerre egy funkcióval kezdj, ne egy egész sémát dobj be:

Adj adatbázist ehhez az apphoz. Hozz létre egy foglalások táblát ügyfélnévvel, e-mail címmel, szolgáltatással, kezdési idővel és státusszal (függőben, megerősítve, lemondva; alapértelmezés: függőben). Mentsd el a foglalási űrlap beküldéseit, mutass sikeres üzenetet, és adj egy adminoldalt, amely a legújabbtól a legrégebbiig listázza a foglalásokat.

Majd bővítsd:

Adj egy szolgáltatások táblát (név, időtartam percben, ár centben). Cseréld le a foglalások szabad szöveges szolgáltatásmezőjét egy hivatkozásra a szolgáltatásokhoz, és migráld a meglévő foglalásokat anélkül, hogy bármit törölnél.

És szigorítsd:

Gondoskodj róla, hogy minden adatbázis-olvasás és -írás a szerveren történjen. A böngésző soha ne kapja meg az adatbázis-kapcsolati stringet. Érvényesítsd az e-mail címet és a kezdési időt a szerveren a beszúrás előtt.

Lépésről lépésre

1. Sorold fel az adataidat a fentiek szerint: dolgok, mezők, kapcsolatok közöttük.
2. Hozd létre az adatbázist. AI-építőben kérd a chatben. Máshol hozz létre egy felügyelt Postgres példányt, és másold ki a kapcsolati stringjét.
3. Tárold a kapcsolati stringet titokként (környezeti változóként a szerveren), soha ne a kódban. Lásd: környezeti változók és titkok.
4. Hozd létre a táblákat. Használj migrációkat – verziózott szkripteket, amelyek módosítják a sémát –, hogy a változtatások megismételhetők és visszavonhatók legyenek.
5. Építsd meg a szerveri útvonalakat, amelyek sorokat hoznak létre, olvasnak, frissítenek és törölnek (CRUD). A böngésző ezeket hívja; soha nem beszél közvetlenül az adatbázissal.
6. Kösd be a felületet ezekhez az útvonalakhoz: mentő űrlapok, betöltő listák, üres állapotok, ha még nincs adat.
7. Teszteld a megmaradást. Küldj be valamit, töltsd újra az oldalt, nyisd meg egy másik böngészőben. Ha az adat nincs ott, nem az adatbázisba mentődött.
8. Ellenőrizd a hozzáférést. Jelentkezz be egy második felhasználóként, és nézd meg, látod-e vagy szerkesztheted-e az első felhasználó adatait.
9. Publikálj, majd teszteld újra az éles URL-en, mert a publikált app más kapcsolatot használhat, mint az előnézeted.

Gyakori hibák

• A böngészőbe mentés, és azt hinni, hogy el van mentve. A localStorage működni látszik, amíg valaki más eszközön meg nem nyitja az appot. Mindig teszteld egy második böngészőben.
• A kapcsolati string a frontend kódban. Bárki olvashatja a frontend kódot. Ezzel az egész adatbázisodhoz hozzáfér.
• Hozzáférés-ellenőrzés hiánya. A „mutasd a rendeléseimet” listának a szerveren kell a bejelentkezett felhasználóra szűrnie, nem a felületen. Ez a leggyakoribb biztonsági rés AI-val épített appokban; a biztonsági ellenőrzőlistánk ezt fedi le.
• Romboló sémamódosítások. Ha azt kéred, hogy „nevezd át a táblát” vagy „változtasd meg a szerkezetet”, a tábla eldobásra és újra létrehozásra kerülhet. Ha valódi adat van, mondd azt: „migráld a meglévő sorokat, ne törölj semmit”.
• Fájlok tárolása az adatbázisban. A képek és PDF-ek fájltárhelyre valók, a táblában csak az URL-jük vagy kulcsuk legyen. Lásd: hogyan adj fájlfeltöltést az appodhoz.
• Nincsenek mentések. Tudd, hogyan mentődnek az adatok a platformodon, és hogyan állíthatod vissza őket, mielőtt lennének ügyfeleid.

Ellenőrzőlista

• Minden dologtípusnak saját táblája van azonosítóval és létrehozási idővel
• A kötelező mezőket és a típusokat az adatbázis kényszeríti ki
• A kapcsolati string csak szerveroldali titkokban van
• Minden olvasás és írás szerveri útvonalakon megy keresztül
• Mindenki csak a saját sorait olvashatja és módosíthatja
• Az adatok túlélik az újratöltést, és más böngészőben is megjelennek
• A sémamódosítások migrációkat használnak, és megtartják a meglévő sorokat
• Tudod, hogyan működnek a mentések és a visszaállítás
• Az éles appot publikálás után is teszteltad

Adatbázis hozzáadása a Mythexben

A Mythexben minden projekt kaphat saját dedikált Postgres adatbázist, a Free és a Pro csomagban is. Általában nem kell külön „csatolás” gombot nyomni: kérd a chatben („mentsd a várólistás e-mail címeket adatbázisba”), vagy írd be a /database parancsot, és a kapcsolati adatok bekerülnek a munkaterületbe és a publikált appba. A projektbeállításokban látszik, hogy aktív-e az adatbázis.

Az adatbázis 5 perc tétlenség után elalszik, és a következő kérésre felébred. A publikált használatot csak arra az időre számítjuk, amíg valóban ébren volt, ugyanabból a kreditegyenlegből, mint az építést. Ha publikálás után adsz hozzá adatbázist, publikálj újra, hogy az éles app is felvegye.

Lásd: Adatbázis és a CRUD-app építése recept a dokumentációban. A felhasználónkénti adatok bejelentkezési oldalához olvasd el: hogyan adj bejelentkezést az appodhoz.

Kérdések