---
term: 'Livello di astrazione del database (DBAL)'
seoTitle: 'Livello di astrazione del database (DBAL): guida completa'
headline: 'Che cos''è un livello di astrazione del database?'
slug: livello-di-astrazione-del-database
category: database
shortDefinition: 'Un livello di astrazione del database è uno strato di API tra il codice e il database che nasconde quale motore, dialetto e driver stiano sotto.'
relatedTerms:
  - auto-generated-database-apis
  - relational-queries-document-databases
  - backend-sdk
  - crud-operations
contrastsWith:
  - auto-generated-database-apis
faq:
  - question: 'Che cos''è un livello di astrazione del database?'
    answer: 'Un''API che sta tra il codice applicativo e il sistema di database, e che presenta un''unica interfaccia coerente per connessioni, query, risultati e transazioni mentre sotto traduce verso il dialetto SQL e il protocollo specifici di ciascun motore. Il codice scritto contro il livello è indipendente dal database: il motore diventa un dettaglio di configurazione invece di una dipendenza rigida.'
  - question: 'Un ORM è la stessa cosa di un livello di astrazione del database?'
    answer: 'Un ORM ne contiene uno, ma va oltre. Un livello di astrazione del database nasconde con quale motore si parla, mentre si continua a ragionare in tabelle e query; un ORM astrae in più il modello relazionale stesso trasformandolo in oggetti – righe mappate su istanze, chiavi esterne su proprietà, con meccanismi come il lazy loading sopra. L''illustrazione canonica è uno stack in cui l''ORM sta sul livello di astrazione, che sta sul driver grezzo.'
  - question: 'Quali sono i livelli di astrazione del database?'
    answer: 'Una scala a quattro pioli. I driver grezzi parlano il protocollo di rete e accettano stringhe SQL nel dialetto. I query builder costruiscono l''SQL per via programmatica – sicuri e componibili, ancora a forma di SQL. Gli ORM mappano le tabelle su oggetti e nascondono quasi del tutto l''SQL. Gli SDK di backend e le API generate automaticamente stanno più in alto: il database diventa un servizio remoto consumato attraverso un''unica interfaccia. Ogni piolo scambia controllo con comodità.'
  - question: 'I livelli di astrazione prevengono la SQL injection?'
    answer: 'Sono la difesa pratica più solida: query parametrizzate ed escaping diventano la strada predefinita invece di una disciplina che ogni sviluppatore deve ricordare. Ma su ogni livello restano le vie d''uscita verso l''SQL grezzo, e la concatenazione di stringhe attraverso quelle riapre il buco. Il livello centralizza la difesa; non abolisce la necessità di attenzione ai margini.'
  - question: 'Che cos''è un''astrazione che perde in questo contesto?'
    answer: 'È quando il comportamento specifico del motore riemerge nonostante il livello: tipi di errore diversi per ogni database, semantica delle transazioni e dei lock differente, oppure una query rapida su un motore e patologica su un altro. La legge classica dice che tutte le astrazioni non banali perdono – il che in pratica significa che il livello risparmia la scrittura di SQL nel dialetto, non la comprensione del motore che sta sotto.'
  - question: 'Si può davvero cambiare database grazie a un livello di astrazione?'
    answer: 'Più onestamente di quanto suggerisca il marketing: il cambio diventa un progetto di porting invece di una riscrittura. Il livello gestisce la traduzione del dialetto, ma i profili di prestazione, il comportamento dei lock e la migrazione dei dati stessa richiedono comunque lavoro vero. Il caso più forte per la portabilità è il software che deve essere distribuito su più motori – prodotti, CMS, strumenti self-hosted – più che una singola app che si tiene aperte le opzioni.'
  - question: 'Quando conviene saltare l''astrazione e scrivere SQL grezzo?'
    answer: 'Sugli hot path: query critiche per le prestazioni dove serve il piano di esecuzione esatto, SQL analitico complesso, operazioni di massa e funzionalità specifiche del motore che il livello non riesce a esprimere. La buona pratica su cui c''è consenso è ibrida – l''astrazione copre il novanta per cento di CRUD di routine, e l''SQL grezzo parametrizzato copre le poche query in cui il controllo si guadagna il posto.'
  - question: 'Quali sono gli esempi più comuni di livelli di astrazione del database?'
    answer: 'Ogni ecosistema ha il suo canone: PDO e Doctrine DBAL in PHP, SQLAlchemy Core in Python, Knex.js in JavaScript, jOOQ in Java e gli standard JDBC/ODBC sotto tutti loro. I livelli dati dei framework e gli SDK di backend sono la stessa idea a un''altitudine più alta – un''unica interfaccia davanti ad archiviazione interscambiabile.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Database abstraction layer (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Database_abstraction_layer'
  - name: 'Doctrine DBAL documentation'
    url: 'https://www.doctrine-project.org/projects/doctrine-dbal/en/4.3/reference/introduction.html'
  - name: 'Comparing SQL, query builders, and ORMs — Prisma Data Guide'
    url: 'https://www.prisma.io/dataguide/types/relational/comparing-sql-query-builders-and-orms'
  - name: 'Should you abstract the database? — Enterprise Craftsmanship'
    url: 'https://enterprisecraftsmanship.com/posts/should-you-abstract-database/'
cta:
  title: 'Un''unica API, qualunque database sotto'
  text: 'Back4app è, in pratica, il piolo più alto della scala dell''astrazione: un solo SDK per query, relazioni e transazioni, con un motore open-source che traduce verso il database sottostante. Il tuo codice non impara mai un dialetto.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-14'
translationKey: database-abstraction-layer
---

**Un livello di astrazione del database è uno strato di API tra il codice e il database che nasconde quale motore, dialetto e driver stiano sotto.** Scrivere contro il livello rende il database una configurazione sostituibile; scrivere contro il motore fa di ogni query un piccolo atto di lock-in. Le domande interessanti sono quanto in alto convenga salire sulla scala dell'astrazione – e quanto costa ciascun piolo.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Un'unica API coerente davanti a motori di database interscambiabili |
| La scala | Driver grezzo → query builder → ORM → SDK/API di backend |
| Che cosa si guadagna | Portabilità, difesa centralizzata dall'injection, testabilità, meno boilerplate |
| Che cosa perde | Errori, semantica delle transazioni, salti nel vuoto nelle prestazioni – le astrazioni perdono sempre |
| Buona pratica | Ibrido: il livello per il CRUD di routine, SQL grezzo per gli hot path |

## La stessa query, quattro altitudini

```javascript
// Piolo 1 · Driver grezzo – il dialetto si scrive a mano, parametrizzato
const { rows } = await pg.query(
  'SELECT * FROM orders WHERE status = $1 AND total > $2',
  ['paid', 100]
);

// Piolo 2 · Query builder – semantica SQL, nessuna stringa di dialetto
const rows = await knex('orders')
  .where('status', 'paid')
  .andWhere('total', '>', 100);

// Piolo 3 · ORM – oggetti, non tabelle
const orders = await Order.findAll({
  where: { status: 'paid', total: { [Op.gt]: 100 } },
});
```

E il quarto piolo – l'SDK di backend, dove sparisce anche la connessione e la stessa chiamata gira da qualunque piattaforma:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The same query whether the store beneath is document- or SQL-shaped
const query = new Parse.Query('Order');
query.equalTo('status', 'paid');
query.greaterThan('total', 100);
query.descending('createdAt');
const orders = await query.find(); // no SQL, no dialect, no driver code
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The same query whether the store beneath is document- or SQL-shaped
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'paid')
  ..whereGreaterThan('total', 100)
  ..orderByDescending('createdAt');
final response = await query.query(); // no SQL, no dialect, no driver code
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The same query whether the store beneath is document- or SQL-shaped
let query = Order.query("status" == "paid", "total" > 100)
  .order([.descending("createdAt")])
query.find { result in
  if case .success(let orders) = result {
    print("\(orders.count) paid orders") // no SQL, no dialect, no driver code
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The same query whether the store beneath is document- or SQL-shaped
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "paid")
query.whereGreaterThan("total", 100)
query.orderByDescending("createdAt")
query.findInBackground { orders, e ->
  if (e == null) Log.d("Orders", "${orders.size} paid orders")
}
```

## Dove si colloca il livello

```mermaid
flowchart LR
  accTitle: Dove si colloca un livello di astrazione del database
  accDescr: Il codice applicativo dialoga con il livello di astrazione – un query builder, un ORM o un SDK – che traduce verso un driver di database, il quale parla il protocollo di rete del motore reale, documentale o SQL.
  A["Codice applicativo"] --> L["Livello di astrazione<br/>query builder · ORM · SDK"]
  L --> D["Driver<br/>protocollo di rete + dialetto"]
  D --> E1[("Motore SQL")]
  D --> E2[("Motore documentale")]
```

| Piolo | Che cosa si scrive | Di cosa si occupa il livello | Controllo | Portabilità |
| --- | --- | --- | --- | --- |
| Driver grezzo | SQL nel dialetto | Connessioni, parametri | Totale | Nessuna |
| Query builder | Codice di query componibile | Generazione dell'SQL, escaping | Alto | Buona |
| ORM | Operazioni su oggetti | SQL, mapping, relazioni | Medio | Buona |
| SDK di backend | L'intento ("find, save") | Tutto, server compreso | Basso, per scelta | Massima |

## DBAL vs. ORM vs. livello di accesso ai dati

Tre termini che nella pratica si confondono, separati in un colpo solo: il **livello di astrazione del database** nasconde *quale motore* – si continua a ragionare in tabelle e query, ma in modo portabile. L'**ORM** nasconde in più *il modello relazionale* – le tabelle diventano classi, le righe diventano oggetti, e con loro arriva tutto un meccanismo (identity map, lazy loading). Il **livello di accesso ai dati** è un termine di architettura: qualunque codice incapsuli la persistenza di un'applicazione, di norma *costruito sopra* uno dei due precedenti. Lo stack canonico lo rende concreto: [Doctrine ORM si appoggia a Doctrine DBAL, che si appoggia al driver grezzo](https://www.doctrine-project.org/projects/doctrine-dbal/en/4.3/reference/introduction.html) – tre ruoli distinti, tre livelli, un solo import per chi programma l'applicazione.

## Il bilancio onesto

Che cosa porta davvero il livello: la **portabilità** (il motore diventa una decisione rivedibile), la **sicurezza per impostazione predefinita** (le query parametrizzate smettono di essere una disciplina e diventano l'unica strada), la **testabilità** (un motore leggero sostituito sotto i test) e **un'unica API** da un progetto all'altro invece di un dialetto per ogni database. Che cosa rimproverano [a ragione i critici](https://enterprisecraftsmanship.com/posts/should-you-abstract-database/): le astrazioni **perdono** – errori specifici del motore, semantica delle transazioni e salti nel vuoto nelle prestazioni risalgono comunque; l'effetto **minimo comune denominatore** taglia fuori proprio le funzionalità specifiche per cui si era scelto quel motore; e la generazione nascosta delle query produce le patologie N+1 che hanno reso celebri gli ORM. Le due colonne sono vere allo stesso tempo – è la ragione per cui la posizione matura è una questione di collocazione, non di fedeltà: astrazione dove il lavoro è di routine, SQL grezzo dove il controllo rende.

## Casi d'uso tipici

- **CRUD applicativo.** Il 90 % di query di routine – dove la coerenza e i valori predefiniti sicuri del livello danno il meglio.
- **Software distribuito per molti database.** Prodotti self-hosted e CMS che devono girare sul motore di cui il cliente dispone – il caso di portabilità più solido.
- **Suite di test.** Un motore locale rapido sotto i test, il motore di produzione in deployment, un'unica codebase.
- **Client multipiattaforma.** Il piolo dell'SDK: web, mobile e server interrogano la stessa API di dati senza che nessun client sappia che esiste un motore di archiviazione.
- **Irrobustire una codebase contro l'injection.** Centralizzare la costruzione delle query perché la strada non sicura sia l'eccezione che salta all'occhio in revisione.

## Conviene astrarre? Matrice decisionale

| Appoggiarsi all'astrazione quando… | Scendere a SQL grezzo quando… |
| --- | --- |
| La query è CRUD di routine | La query è un hot path misurato |
| Il team mescola livelli di esperienza diversi | Serve il piano di esecuzione esatto, con gli hint |
| La portabilità è un requisito reale | Le funzionalità specifiche del motore sono tutto il punto |
| I test hanno bisogno di un motore sostituibile | Si tratta di SQL analitico di complessità reale |
| La coerenza tra i servizi conta | L'astrazione fa resistenza tre volte nello stesso file |

L'ultima riga è il segnale pratico: quando si finisce per contorcere l'API del livello per esprimere ciò che una singola istruzione SQL dice in chiaro, quella query si è guadagnata la sua via d'uscita.

## Limiti e trade-off

- **La perdita è garantita; varia solo la sua entità.** Conviene mettere in conto di capire comunque il motore – il livello cambia ciò che si digita, non ciò che si deve sapere.
- **Le prestazioni si nascondono un livello più in basso.** Le query generate meritano la stessa ispezione di quelle scritte a mano; il problema N+1 è una malattia dei livelli di astrazione.
- **La portabilità è un progetto, non un interruttore.** Il livello trasforma una riscrittura in un porting – è prezioso, ma nessuno cambia motore nella pausa pranzo.
- **Il livello è una dipendenza con un ciclo di vita proprio.** I suoi bug, le sue versioni e i suoi partiti presi diventano i propri.
- **Più il piolo è alto, più vincola.** L'astrazione a livello di SDK è la più produttiva e la più prescrittiva – il trade-off giusto esattamente quando le esigenze del backend sono standard.

## Il livello di astrazione su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È il quarto piolo diventato prodotto: la query dell'SDK nei tab qui sopra costituisce l'intera interfaccia dei dati – nessun dialetto, nessun driver, nessuna stringa di connessione nel codice client – e un motore open-source si occupa della traduzione sotto, con adattatori che coprono motori documentali e SQL. Il consueto trade-off della scala si attenua ai margini di questo piolo: la potenza grezza resta disponibile lato server, in Cloud Code, per gli hot path, e la base open-source impedisce al livello stesso di diventare il lock-in che doveva prevenire.