Cos'è un ORM? Come le app parlano con i database, spiegato

Un ORM (object-relational mapper) è una libreria di codice che si trova tra un'app e un database relazionale. Invece di scrivere query in SQL, gli sviluppatori lavorano con i dati come normali oggetti nel loro linguaggio di programmazione — db.booking.create(...) oppure Booking.find(...) — e l'ORM traduce tutto in SQL, lo esegue e trasforma i risultati di nuovo in oggetti. Esempi diffusi sono Prisma e Drizzle per TypeScript, SQLAlchemy per Python ed Entity Framework Core per C#.

Perché gli ORM contano quando costruisci con l'AI

Quando un AI app builder aggiunge un database alla tua app, di solito aggiunge anche un ORM per comunicarci. Non dovrai scrivere codice ORM, ma è utile sapere che c'è:

• Il modello dei dati vive nel codice. Il file dello schema dell'ORM è spesso la descrizione più chiara dei dati della tua app: quali tabelle esistono, quali campi ha ciascuna e come sono collegate. Leggerlo è un modo rapido per verificare che l'AI abbia capito la tua app.
• Le modifiche al database passano dalle migrazioni. Quando chiedi «aggiungi un numero di telefono ai clienti», l'AI aggiorna il modello e crea una migrazione. Saperlo aiuta a capire perché una modifica possa dover essere applicata prima di funzionare online.
• Sicurezza di default. Gli ORM costruiscono le query in modo da proteggere dalla SQL injection, una delle falle più comuni nelle app che assemblano le query a mano.
• Trappole di velocità. Gli ORM rendono facile eseguire per sbaglio centinaia di piccole query dove ne basterebbe una. È una causa frequente di pagine lente nelle app costruite con l'AI.

Un'analogia quotidiana

Immagina un viaggiatore britannico e un negoziante giapponese che non condividono una lingua e parlano tramite un interprete.

Il viaggiatore (la tua app) dice: «Vorrei i tre tè più economici che avete.» L'interprete (l'ORM) lo traduce in giapponese preciso (SQL), lo passa al negoziante (il database) e traduce la risposta di nuovo in inglese.

Il viaggiatore non impara mai il giapponese, e per la maggior parte delle conversazioni va benissimo. Ma per una trattativa complicata può essere utile parlare direttamente — ecco perché la maggior parte degli ORM permette agli sviluppatori di scrivere SQL grezzo quando serve.

Come funziona un ORM

Database come Postgres memorizzano i dati in tabelle di righe e colonne e si interrogano con SQL. I linguaggi di programmazione lavorano con oggetti: una prenotazione con una date, un customer e uno status. L'ORM mette in corrispondenza i due mondi:

Queste quattro operazioni sono le azioni CRUD su cui si basa quasi ogni app.

Un esempio pratico: prenotazioni con Prisma

Ecco uno schema Prisma semplificato per un'app di prenotazioni di un salone. Descrive due tabelle e come sono collegate:

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
}

In parole semplici: un cliente ha un nome, un'email unica e molte prenotazioni; ogni prenotazione ha un orario di inizio, un servizio e appartiene a un solo cliente.

Ora l'app vuole «le prossime prenotazioni di Lena, dalla più vicina»:

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

L'ORM la trasforma in SQL più o meno così, la esegue e restituisce un elenco di oggetti prenotazione:

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;

I $1 e $2 sono segnaposto: l'email e la data vengono inviate separatamente dal testo della query, ed è questo che impedisce la SQL injection.

Migrazioni

Se poi chiedi «fai in modo che i clienti possano aggiungere un numero di telefono», l'AI aggiunge phone String? al modello Customer (il ? indica che il campo è facoltativo) e genera una migrazione — un piccolo script SQL come ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. Le migrazioni vengono salvate in ordine, così ogni copia del database può essere portata alla stessa struttura, e la cronologia delle modifiche resta conservata.

Gli ORM più comuni per linguaggio

Gli ORM variano nella quantità di SQL che nascondono. Prisma usa un proprio linguaggio di schema e un proprio stile di query; Drizzle resta volutamente vicino alla forma dell'SQL mantenendo tutto tipizzato. Strumenti più leggeri chiamati query builder, come Knex o Kysely per TypeScript, aiutano a costruire SQL nel codice senza trasformare le righe in oggetti completi.

Termini chiave

Idee sbagliate comuni

• «Un ORM è un database.» Non è così. È un traduttore. Ti serve comunque un database come Postgres.
• «Con un ORM non serve capire i propri dati.» Tabelle mal progettate creano gli stessi problemi anche attraverso un ORM. Un buon modello dei dati conta più dello strumento.
• «Gli ORM sono sempre lenti.» Le query di tutti i giorni vanno bene. La lentezza di solito nasce da schemi come le query N+1 o dagli indici mancanti, e si può correggere.
• «Con un ORM non c'è mai rischio di SQL injection.» I metodi standard dell'ORM sono sicuri, ma l'SQL grezzo che include input dell'utente incollato direttamente è ancora pericoloso.
• «Modificare il file dello schema cambia il database attivo.» Succede solo dopo che una migrazione è stata creata e applicata a quel database.

Cosa chiedere al tuo AI builder

• «Mostrami lo schema del database e spiegami ogni tabella e relazione in parole semplici.»
• «Quale ORM usa questo progetto e dove si trovano le migrazioni?»
• «Prima di modificare una tabella, dimmi se i dati esistenti verranno influenzati, e non eliminare mai una colonna che contiene dati senza chiedermelo.»
• «Controlla le pagine più lente per query N+1 e aggiungi indici dove le liste vengono filtrate o ordinate.»
• «Assicurati che ogni query che usa input dell'utente passi dall'ORM o usi parametri — niente SQL costruito con stringhe.»

ORM in Mythex

Quando la tua app deve salvare dati, Mythex aggiunge al progetto un database Postgres dedicato — chiedilo in chat o usa il comando /database — e ne inserisce i dettagli di connessione nello spazio di lavoro e nell'app pubblicata (Database). Poi l'agente scrive il codice che legge e salva i tuoi dati. Se hai una preferenza — «usa Prisma», «usa SQLAlchemy» o «SQL semplice, niente ORM» — dillo in chat. Quando vuoi verificare la struttura, chiedigli di illustrarti lo schema; puoi leggere i file anche nell'editor di codice. Per il quadro generale, vedi cos'è un database e SQL vs NoSQL.

Domande