Hvad er en ORM? Sådan taler apps med databaser, forklaret

En ORM (object-relational mapper) er et kodebibliotek, der sidder mellem en app og en relationel database. I stedet for at skrive databaseforespørgsler i SQL arbejder udviklere med data som almindelige objekter i deres programmeringssprog — db.booking.create(...) eller Booking.find(...) — og ORM'en oversætter det til SQL, kører det og omdanner resultaterne tilbage til objekter. Kendte eksempler er Prisma og Drizzle til TypeScript, SQLAlchemy til Python og Entity Framework Core til C#.

Hvorfor ORM'er betyder noget, når du bygger med AI

Når en AI-app-builder tilføjer en database til din app, tilføjer den typisk også en ORM til at tale med den. Du behøver ikke skrive ORM-kode selv, men det hjælper at vide, at den er der:

• Din datamodel lever i koden. ORM'ens schema-fil er ofte den tydeligste beskrivelse af din apps data: hvilke tabeller der findes, hvilke felter hver har, og hvordan de hænger sammen. At læse den er en hurtig måde at tjekke, at AI'en har forstået din app.
• Ændringer i databasen går gennem migrationer. Når du beder om "tilføj et telefonnummer til kunder", opdaterer AI'en modellen og laver en migration. Det hjælper dig med at forstå, hvorfor en ændring måske skal anvendes, før den virker live.
• Sikkerhed som standard. ORM'er bygger forespørgsler på en måde, der beskytter mod SQL-injection, et af de mest almindelige sikkerhedshuller i apps, der samler forespørgsler i hånden.
• Fælder for ydelsen. ORM'er gør det let at køre hundredvis af små forespørgsler, hvor én ville have været nok. Det er en almindelig årsag til langsomme sider i AI-byggede apps.

En hverdagsanalogi

Forestil dig en britisk rejsende og en japansk butiksindehaver, der ikke deler et sprog og taler gennem en tolk.

Den rejsende (din app) siger: "Jeg vil gerne have de tre billigste teer, I har." Tolken (ORM'en) oversætter det til præcist japansk (SQL), giver det til butiksindehaveren (databasen) og oversætter svaret tilbage til engelsk.

Den rejsende lærer aldrig japansk, og til de fleste samtaler er det helt fint. Men til en kompliceret forhandling kan det hjælpe at tale direkte — og derfor lader de fleste ORM'er udviklere skrive rå SQL, når der er behov for det.

Sådan virker en ORM

Databaser som Postgres gemmer data i tabeller med rækker og kolonner og forespørges med SQL. Programmeringssprog arbejder med objekter: en booking med en date, en customer og en status. ORM'en kobler de to sammen:

De fire operationer er de CRUD-handlinger, næsten alle apps bygger på.

Et konkret eksempel: bookinger med Prisma

Her er et forenklet Prisma-schema for en frisør-bookingapp. Det beskriver to tabeller og hvordan de er forbundet:

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
}

På almindeligt dansk: en kunde har et navn, en unik e-mail og mange bookinger; hver booking har et starttidspunkt, en ydelse og hører til én kunde.

Nu vil appen have "Lenas kommende bookinger, tidligste først":

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

ORM'en omsætter det til SQL nogenlunde sådan her, kører det og returnerer en liste af booking-objekter:

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;

$1 og $2 er pladsholdere: e-mailen og datoen sendes separat fra selve forespørgselsteksten, og det er det, der forhindrer SQL-injection.

Migrationer

Hvis du derefter beder om "lad kunderne tilføje et telefonnummer", tilføjer AI'en phone String? til Customer-modellen (? betyder valgfri) og genererer en migration — et lille SQL-script som ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. Migrationer gemmes i rækkefølge, så alle kopier af databasen kan bringes til samme struktur, og historikken over ændringer bevares.

Almindelige ORM'er efter sprog

ORM'er varierer i, hvor meget de skjuler SQL. Prisma bruger sit eget schema-sprog og sin egen forespørgselsstil; Drizzle holder sig bevidst tæt til SQL's form og gør alt typesikkert. Lettere værktøjer, der kaldes query builders, som Knex eller Kysely til TypeScript, hjælper med at bygge SQL i koden uden at kortlægge rækker til fulde objekter.

Vigtige begreber

Almindelige misforståelser

• "En ORM er en database." Det er den ikke. Den er en oversætter. Du har stadig brug for en database som Postgres.
• "Med en ORM behøver du ikke forstå dine data." Dårligt designede tabeller er lige så besværlige gennem en ORM. En god datamodel betyder mere end værktøjet.
• "ORM'er er altid langsomme." Almindelige forespørgsler er fine. Langsomhed kommer typisk fra mønstre som N+1-forespørgsler eller manglende indekser, og det kan rettes.
• "ORM betyder ingen risiko for SQL-injection, nogensinde." Standardmetoderne i en ORM er sikre, men rå SQL, hvor brugerinput indsættes direkte, er stadig farligt.
• "Ændring af schema-filen ændrer den live database." Kun når en migration er oprettet og anvendt på den database.

Hvad du spørger din AI-builder om

• "Vis mig databaseschemaet, og forklar hver tabel og relation på almindeligt dansk."
• "Hvilken ORM bruger dette projekt, og hvor ligger migrationerne?"
• "Før du ændrer en tabel, så fortæl mig, om eksisterende data påvirkes, og slet aldrig en kolonne med data uden at spørge først."
• "Tjek de langsomste sider for N+1-forespørgsler, og tilføj indekser, hvor lister filtreres eller sorteres."
• "Sørg for, at alle forespørgsler med brugerinput går gennem ORM'en eller bruger parametre — ingen SQL bygget af strenge."

ORM'er i Mythex

Når din app skal gemme data, tilføjer Mythex en dedikeret Postgres-database til projektet — spørg i chatten eller brug kommandoen /database — og indsætter forbindelsesoplysningerne i workspace og den publicerede app (Database). Agenten skriver derefter koden, der læser og gemmer dine data. Har du en præference — "brug Prisma", "brug SQLAlchemy" eller "ren SQL, ingen ORM" — så sig det i chatten. Bed den gennemgå schemaet, når du vil tjekke strukturen; du kan læse filerne i kodeeditoren. For det større billede, se hvad er en database og SQL vs. NoSQL.

Spørgsmål