SQL e DuckDB

La lingua in cui i dati vivono già.

SQL non è un programma, è la lingua con cui si chiede qualcosa a un database. Esiste da cinquant'anni, è cambiata pochissimo, ed è l'unica competenza di questo elenco che sopravvive a qualsiasi moda tecnologica. Se i vostri dati sono più di un foglio di calcolo, da qualche parte stanno dentro un database, e quella è la lingua che parla.

Perché conta anche se non fate i sistemisti

La differenza pratica è dove avviene il calcolo. Esportare un flusso in un file e poi contarlo sul proprio computer significa portarsi a casa milioni di righe per ottenere una tabella di venti. Scrivere la domanda in SQL significa lasciare il lavoro al database e ricevere solo il risultato. Cambia i tempi, cambia la memoria che serve, e riduce il numero di copie di dati sensibili in circolazione.

Dove lavorano SQL e DuckDB nella filiera dei datiLeggereGestire ilvolumeControllareAnalizzareComunicareSQL e DuckDBRHO
SQL e DuckDB lavorano all'inizio della filiera: leggere i dati e reggerne il volume, prima dell'analisi.

DuckDB, che cos'è e cosa non è

DuckDB è un database che non ha bisogno di un server: è una libreria che gira dentro R, dentro Python o da riga di comando, e interroga file che avete già sul disco, anche in formato parquet, senza doverli prima caricare in memoria. Serve a lavorare in locale su dati che non ci starebbero, non a sostituire il database aziendale.

Il formato dei file

La coppia che funziona è parquet più DuckDB. Parquet è un formato a colonne: occupa molto meno di un CSV e consente di leggere solo le colonne che servono. Su un archivio di qualche milione di righe, che siano ricoveri, movimenti contabili o risposte a un questionario, la differenza rispetto al CSV non è di stile, è di ordini di grandezza, e si misura.

Un esempio: dodici mesi di movimenti in una tabella

Un archivio di movimenti contabili salvato in più file parquet, uno per mese. La domanda è quanti movimenti e quale importo totale per ogni mese del 2025. Da R bastano poche righe, e i file non vengono mai caricati per intero:

library(DBI)
library(duckdb)

con <- dbConnect(duckdb())

dbGetQuery(con, "
  SELECT strftime(date, '%Y-%m') AS month,
         COUNT(*)                AS n_transactions,
         SUM(amount)             AS total
  FROM read_parquet('transactions/*.parquet')
  WHERE year = 2025
  GROUP BY month
  ORDER BY month
")

dbDisconnect(con)

DuckDB legge solo le colonne che servono e restituisce dodici righe. La stessa domanda si può scrivere in dplyr: il pacchetto dbplyr la traduce in SQL, e show_query() mostra l'SQL generato prima di eseguirlo. È il modo più semplice per imparare la lingua leggendola.

Gli errori che si fanno tutti

  • I valori mancanti. COUNT(*) conta le righe, COUNT(colonna) conta solo i valori presenti, e una media ignora i mancanti senza avvisare. Due conteggi che dovrebbero coincidere spesso differiscono per questo.
  • Le condizioni con i mancanti. WHERE type <> 'A' esclude anche le righe in cui il tipo è mancante. Se servono, vanno richieste esplicitamente con OR type IS NULL.
  • Le unioni che moltiplicano le righe. Se la chiave non è unica in una delle due tabelle, un'unione duplica le righe e i totali crescono in silenzio. Prima di unire conviene contare le chiavi doppie.
  • Le date. Ogni database le formatta e le confronta con funzioni proprie: è il primo punto in cui una query si rompe passando da un sistema all'altro.

Il punto delicato: i dialetti

SQL è standard sulla carta. Nella pratica, date, stringhe e funzioni di finestra cambiano fra Oracle, SQL Server, PostgreSQL e gli altri, e una query che funziona in sviluppo può rompersi in produzione. È il motivo per cui conviene scrivere le trasformazioni in modo che il linguaggio venga generato, e leggere sempre l'SQL prodotto prima di fidarsi.

In azienda

È la cosa più facile da ottenere di tutte: un accesso in sola lettura a una vista, concordato con i sistemi informativi. Non richiede installazioni, non muove dati, e spesso è l'unica strada ammessa dalle politiche interne.

Dove si prende

SQL non si installa: è già dentro il database. Per scrivere query su un database aziendale serve solo un client: DBeaver, nella versione Community, è gratuito e si collega ai sistemi più diffusi. DuckDB è gratuito e con licenza MIT. In R si installa con install.packages("duckdb"), in Python con pip install duckdb, e da riga di comando è un singolo eseguibile scaricabile da duckdb.org, senza installazione.

Per imparare

Il tutorial interattivo SQLBolt per le basi della lingua. Il capitolo sui database di R for Data Science, gratuito online, per usarla da R. La documentazione ufficiale di DuckDB, chiara e piena di esempi.

Quando ha senso impararlo

Se lavorate su flussi, sempre. È la competenza con il miglior rapporto fra tempo di apprendimento e autonomia guadagnata: con due giorni di studio smettete di dipendere da chi vi prepara l'estrazione.

Vedi anche

R · Python · Quarto

Volete interrogare i vostri flussi senza passare dalle esportazioni?