Mi az ORM? Hogyan beszélnek az appok az adatbázisokkal, magyarázattal

Az ORM (objektum-relációs leképező) egy kódkönyvtár, amely az app és a relációs adatbázis között helyezkedik el. SQL-ben írt adatbázis-lekérdezések helyett a fejlesztők az adatokkal közönséges objektumokként dolgoznak a programozási nyelvükben – db.booking.create(...) vagy Booking.find(...) formában –, az ORM pedig ezt lefordítja SQL-re, lefuttatja, és az eredményeket visszaalakítja objektumokká. Ismert példák a TypeScripthez a Prisma és a Drizzle, a Pythonhoz a SQLAlchemy, a C#-hoz pedig az Entity Framework Core.

Miért fontosak az ORM-ek, ha AI-val építesz

Amikor egy AI appépítő adatbázist ad az appodhoz, általában ORM-et is ad hozzá, hogy kommunikálni tudjon vele. ORM-kódot nem kell írnod, de érdemes tudni, hogy ott van:

• Az adatmodell kódban él. Az ORM sémafájlja gyakran a legvilágosabb leírása az app adatainak: hogy mely táblák léteznek, milyen mezőik vannak, és hogyan kapcsolódnak egymáshoz. Ennek átolvasása gyors módja annak, hogy ellenőrizd, jól értette-e az AI az appodat.
• Az adatbázis-változások migrációkon keresztül történnek. Amikor azt kéred, hogy „adjunk telefonszámot a vásárlókhoz”, az AI frissíti a modellt és létrehoz egy migrációt. Ha ezt tudod, érthető, miért kell egy változtatást alkalmazni ahhoz, hogy élesben működjön.
• Alapértelmezetten biztonságos. Az ORM-ek úgy építik fel a lekérdezéseket, hogy védenek az SQL-injekció ellen, ami az egyik leggyakoribb biztonsági rés olyan appokban, ahol a lekérdezéseket kézzel állítják össze.
• Sebességi csapdák. Az ORM-mel könnyű véletlenül sok apró lekérdezést futtatni ott, ahol egy is elég lenne. Ez gyakori oka annak, hogy az AI-val épített appok oldalai lassúak.

Mindennapi hasonlat

Képzelj el egy brit utazót és egy japán eladót, akik nem beszélnek közös nyelvet, és tolmács segítségével értik meg egymást.

Az utazó (az app) ezt mondja: „Kérem a három legolcsóbb teát, amit van.” A tolmács (az ORM) pontos japán nyelvre (SQL) fordítja, átadja az eladónak (az adatbázisnak), a választ pedig visszafordítja angolra.

Az utazónak nem kell megtanulnia japánul, és a legtöbb beszélgetéshez ez így rendben van. Egy bonyolult tárgyaláshoz viszont jól jöhet, ha közvetlenül beszél – ezért engedik a legtöbb ORM-ek, hogy a fejlesztők szükség esetén nyers SQL-t írjanak.

Hogyan működik az ORM

Az adatbázisok, mint a Postgres, az adatokat sorokból és oszlopokból álló táblákban tárolják, és SQL segítségével kérdezik le. A programozási nyelvek objektumokkal dolgoznak: egy foglalás egy date dátummal, egy customer vásárlóval és egy status állapottal. Az ORM ezt a kettőt felelteti meg egymásnak:

Ezek a négy művelet a CRUD műveletek, amelyekre szinte minden app épül.

Példa: foglalások Prismával

Íme egy egyszerűsített Prisma-séma egy szalonfoglaló apphoz. Két táblát ír le és azt, hogyan kapcsolódnak:

model Customer {
  id       Int       @id @default(autoincrement())
  name     String
  email    String    @unique
  bookings Booking[]
}

model Booking {
  id         Int      @id @default(autoincrement())
  startsAt   DateTime
  service    String
  customer   Customer @relation(fields: [customerId], references: [id])
  customerId Int
}

Egyszerűen szólva: egy vásárlónak van neve, egyedi e-mail-címe és több foglalása; minden foglalásnak van kezdési ideje, szolgáltatása, és egy vásárlóhoz tartozik.

Az app most azt kéri: „Lena közelgő foglalásai, a legkorábbi elöl”:

const bookings = await db.booking.findMany({
  where: {
    customer: { email: "lena@example.com" },
    startsAt: { gte: new Date() },
  },
  orderBy: { startsAt: "asc" },
});

Az ORM ezt nagyjából ilyen SQL-re fordítja, lefuttatja, és foglalás-objektumok listáját adja vissza:

SELECT b.* FROM "Booking" b
JOIN "Customer" c ON c.id = b."customerId"
WHERE c.email = $1 AND b."startsAt" >= $2
ORDER BY b."startsAt" ASC;

A $1 és $2 helyőrzők: az e-mail-cím és a dátum külön küldődik a lekérdezés szövegétől, és ez akadályozza meg az SQL-injekciót.

Migrációk

Ha ezután azt kéred, hogy „a vásárlók adhassanak meg telefonszámot”, az AI hozzáadja a phone String? mezőt a Customer modellhez (a ? jelentése: nem kötelező), és létrehoz egy migrációt – egy kis SQL-szkriptet, például ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. A migrációk sorrendben mentődnek, így az adatbázis minden példánya ugyanarra a szerkezetre hozható, és a változások története megmarad.

Gyakori ORM-ek nyelvenként

Az ORM-ek abban térnek el, mennyire rejtik el az SQL-t. A Prisma saját sémanyelvet és lekérdezési stílust használ; a Drizzle szándékosan közel marad az SQL felépítéséhez, miközben mindent típusos marad. A könnyebb eszközök, az úgynevezett lekérdezésépítők, például a Knex vagy a Kysely TypeScripthez, SQL-t segítenek kódban összerakni anélkül, hogy a sorokat teljes objektumokká képeznék le.

Kulcsfogalmak

Gyakori tévhitek

• „Az ORM egy adatbázis.” Nem az. Egy fordító. Szükséged van továbbra is egy adatbázisra, például Postgresre.
• „ORM-mel nem kell érteni az adataidat.” A rosszul megtervezett táblák ORM-mel is fájdalmasak. Egy jó adatmodell fontosabb, mint az eszköz.
• „Az ORM-ek mindig lassúak.” A mindennapi lekérdezések rendben vannak. A lassúság általában olyan mintákból ered, mint az N+1 lekérdezések vagy a hiányzó indexek, és ezek javíthatók.
• „Az ORM azt jelenti, hogy sosincs SQL-injekciós kockázat.” A szokásos ORM-metódusok biztonságosak, de a beillesztett felhasználói bemenettel írt nyers SQL továbbra is veszélyes.
• „A sémafájl szerkesztése megváltoztatja az élő adatbázist.” Csak akkor, ha létrejön egy migráció, és azt alkalmazzák arra az adatbázisra.

Mit kérdezz az AI-építőtől

• „Mutasd meg az adatbázis-sémát, és magyarázd el közérthetően minden táblát és kapcsolatot.”
• „Melyik ORM-et használja ez a projekt, és hol vannak a migrációk?”
• „Mielőtt bármelyik táblát módosítod, mondd meg, érinti-e ez a meglévő adatokat, és soha ne dobj el adatot tartalmazó oszlopot a kérdezésem nélkül.”
• „Nézd át a leglassabb oldalakat N+1 lekérdezések szempontjából, és adj indexeket ott, ahol listákat szűrünk vagy rendezünk.”
• „Biztosítsd, hogy minden felhasználói bemenetet használó lekérdezés az ORM-en keresztül menjen, vagy paramétereket használjon – sztringből összerakott SQL nélkül.”

ORM-ek a Mythexben

Ha az appodnak adatokat kell mentenie, a Mythex egy külön Postgres-adatbázist ad a projekthez – kérd a chatben, vagy használd a /database parancsot –, és a kapcsolódási adatait a munkaterületbe és a közzétett appba építi be (Adatbázis). Az ügynök ezután megírja a kódot, amely olvassa és menti az adataidat. Ha van elképzelésed – „használj Prismát”, „használj SQLAlchemyt”, vagy „sima SQL, ORM nélkül” –, mondd meg a chatben. Kérd meg, hogy vezessen végig a sémán, amikor csak szeretnéd ellenőrizni a szerkezetet; a fájlokat a kódszerkesztőben is megnézheted. A nagyobb képért lásd mi az adatbázis és SQL vs NoSQL.

Kérdések