Che cos'è una query sul database?

Una query sul database è una richiesta strutturata di dati – filtrare, ordinare, proiettare, paginare – scritta in un linguaggio che il motore esegue. L’idea profonda sotto ogni linguaggio di query è la dichiaratività: si descrive il risultato, e il motore sceglie il percorso. Basta padroneggiare una volta i cinque verbi e il modello di costo, e ogni sintassi – SQL, API documentali, GraphQL, builder degli SDK – diventa un accento, non una lingua nuova.

Punti chiave

La stessa query in quattro linguaggi di query

La stessa richiesta – articoli pubblicati, oltre 1.000 visualizzazioni, dal più recente – attraverso le famiglie di linguaggi:

-- SQL: il dichiarativo originale
SELECT title, views FROM articles
WHERE  status = 'published' AND views > 1000
ORDER  BY published_at DESC
LIMIT  20;

// API di query documentale
db.articles.find(
  { status: 'published', views: { $gt: 1000 } },  // filtrare
  { title: 1, views: 1 }                          // proiettare
).sort({ publishedAt: -1 }).limit(20)

// GraphQL: i client dichiarano la forma che vogliono ricevere
query {
  articles(where: { status: "published", views_gt: 1000 },
           orderBy: publishedAt_DESC, first: 20) {
    title
    views
  }
}

E il builder dell’SDK – la superficie che il codice applicativo usa davvero, compilata nella stessa anatomia:

// JavaScript / Node.js — Back4app JS SDK
// Filter, sort, project, paginate — the full anatomy in one query
const query = new Parse.Query('Article');
query.equalTo('status', 'published');       // filter
query.greaterThan('views', 1000);           // filter (range)
query.descending('publishedAt');            // sort
query.select('title', 'views');             // project: only these fields
query.limit(20).skip(40);                   // paginate: page 3
const articles = await query.find();

// Flutter / Dart — Back4app Flutter SDK
// Filter, sort, project, paginate — the full anatomy in one query
final query = QueryBuilder<ParseObject>(ParseObject('Article'))
  ..whereEqualTo('status', 'published')     // filter
  ..whereGreaterThan('views', 1000)         // filter (range)
  ..orderByDescending('publishedAt')        // sort
  ..keysToReturn(['title', 'views'])        // project: only these fields
  ..setLimit(20)..setAmountToSkip(40);      // paginate: page 3
final response = await query.query();

// iOS / Swift — Back4app Swift SDK
// Filter, sort, project, paginate — the full anatomy in one query
let query = Article.query("status" == "published", "views" > 1000)
  .order([.descending("publishedAt")])      // sort
  .select("title", "views")                 // project: only these fields
  .limit(20).skip(40)                       // paginate: page 3
query.find { result in
  if case .success(let articles) = result { render(articles) }
}

// Android / Kotlin — Back4app Android SDK
// Filter, sort, project, paginate — the full anatomy in one query
val query = ParseQuery.getQuery<ParseObject>("Article")
query.whereEqualTo("status", "published")   // filter
query.whereGreaterThan("views", 1000)       // filter (range)
query.orderByDescending("publishedAt")      // sort
query.selectKeys(listOf("title", "views"))  // project: only these fields
query.limit = 20; query.skip = 40           // paginate: page 3
query.findInBackground { articles, e -> if (e == null) render(articles) }

Come un database esegue una query

L’ottimizzatore è la ragione per cui le query dichiarative funzionano: pesa gli indici disponibili, stima il numero di righe e sceglie il piano meno costoso – e EXPLAIN ne mostra la decisione. Il metodo di performance in una riga: lanciare EXPLAIN, cercare la scansione completa, aggiungere l’indice che il filtro sta implorando, guardare di nuovo.

Dichiarativo vs. imperativo

L’anatomia che si ritrova in tutti: filtrare (WHERE), ordinare (ORDER BY), proiettare (la lista del SELECT – chiedere solo ciò che serve), paginare (LIMIT più offset o cursore), aggregare (GROUP BY e affini). Cinque verbi, tutte le superfici.

Le due regole che evitano la maggior parte degli incidenti da query

Parametrizzare, sempre. L’injection è un input ostile che diventa struttura della query – un problema risolto del tutto da segnaposto che associano l’input come valore:

// Vulnerabile: input concatenato nella struttura della query
db.query(`SELECT * FROM users WHERE name = '${input}'`);   // mai così

// Sicuro: parametrizzato – l'input è un dato, non sintassi
db.query('SELECT * FROM users WHERE name = $1', [input]);

I builder degli SDK e le variabili GraphQL lo fanno per costruzione – una delle vittorie silenziose, in termini di sicurezza, delle superfici di query di livello più alto.

Paginare secondo la forma dell’accesso. La paginazione per offset (LIMIT 20 OFFSET 400) permette di arrivare a qualunque pagina, ma paga la profondità in modo lineare e vacilla sotto le scritture concorrenti; la paginazione per cursore (WHERE published_at < $last) è stabile e a costo costante a qualunque profondità, ma avanza solo in un senso. Feed e scroll infinito vogliono i cursori; le tabelle di amministrazione numerate per pagina sono il terreno legittimo dell’offset.

Casi d’uso tipici

• Letture applicative. Viste a elenco, schermate di dettaglio, ricerca – il quartetto filtra-ordina-proietta-pagina nel suo habitat naturale.
• Aggregazione e reporting. Conteggi, somme, sintesi raggruppate – spinti nel motore, dove stanno i dati, invece di essere calcolati nel codice applicativo.
• Superfici di API. Le API generate automaticamente traducono parametri di URL o selezioni GraphQL in queste stesse query – l’anatomia traspare attraverso ogni astrazione.
• Filtri in tempo reale. Le sottoscrizioni live sono query permanenti – gli stessi predicati, valutati di continuo.
• Fare debug in produzione. EXPLAIN più il log delle query lente è il ciclo di diagnosi per la categoria di incidenti “è diventato lento”.

Linguaggio nativo, builder o SDK? Matrice decisionale

La regola onesta della discussione sui livelli di astrazione vale parola per parola: builder per il 90 % di routine, query native dove il controllo si ripaga – e la conoscenza dell’anatomia si trasferisce in entrambi i casi.

Limiti e trade-off

• Il dichiarativo non è gratuito. L’ottimizzatore vale quanto valgono le sue statistiche e i suoi indici; una query giusta su indici sbagliati resta lenta.
• Le query nascondono il proprio costo. Una riga di catena del builder può essere una scansione su milioni di righe; EXPLAIN è l’unico specchio onesto.
• La trappola N+1 vive sopra la query. Query singole perfette, emesse dentro un ciclo, sono collettivamente patologiche – il batching e gli include esistono per questo.
• La paginazione profonda degrada. La profondità dell’offset ha costo lineare; conviene progettare i feed intorno ai cursori dal primo giorno.
• La proliferazione dei linguaggi è reale. SQL, API documentali, GraphQL, DSL di ricerca – ogni superficie costa una tassa al team; l’anatomia condivisa è l’antidoto.

Le query 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 suo approccio alle query è la via del builder dell’SDK portata fino in fondo: il query builder di ogni SDK – i tab di codice qui sopra – compila filtrare, ordinare, proiettare e paginare in query parametrizzate senza superficie di injection, include() gestisce le relazioni senza cicli N+1, gli stessi predicati alimentano le live queries per gli aggiornamenti in tempo reale, e GraphQL serve i client che vogliono dichiarare la propria forma. Cinque verbi, tutte le superfici, un solo backend.