Come Donald Chamberlin contribuì a inventare SQL in IBM, perché la sua sintassi simile all'inglese era importante e come SQL è diventato il modo standard per interrogare i database.
Donald D. Chamberlin non è un nome familiare al grande pubblico, ma il suo lavoro ha cambiato in modo silenzioso il modo in cui la maggior parte dei team software gestisce i dati. Come ricercatore in IBM, Chamberlin ha co-creato SQL (originariamente scritto SEQUEL), il linguaggio che ha reso pratico per gli sviluppatori di tutti i giorni—e persino per non specialisti—porre domande a grandi database.
Prima di SQL, ottenere risposte dai dati conservati spesso significava scrivere programmi personalizzati o usare strumenti potenti ma scomodi. Chamberlin contribuì a promuovere un'idea diversa: invece di dire al computer come trovare i dati passo dopo passo, dovresti poter descrivere cosa vuoi in una forma che si avvicina all'inglese (o, più in generale, al linguaggio naturale).
Al centro di SQL c'è un approccio sorprendentemente amichevole:
SELECT)FROM)WHERE)Questa struttura oggi suona ovvia, ma fu un cambiamento importante. Trasformò «interrogare un database» da un compito da specialisti in qualcosa che poteva essere insegnato, condiviso, revisionato e migliorato—come qualsiasi altra parte dello sviluppo software.
Questa è una storia pratica di come SQL è nato e del perché si è diffuso così tanto.
Non serviranno matematica avanzata, logica formale o teoria avanzata dei database per seguirlo. Ci concentreremo sui problemi del mondo reale che SQL ha risolto, sul perché il suo design era accessibile e su come è diventata una competenza di base nell'industria del software—dallo sviluppo backend all'analisi, al lavoro prodotto e alle operation.
Se hai mai filtrato una lista, raggruppato risultati o unito due insiemi di informazioni, stavi già pensando nella direzione che SQL ha reso comune. Il contributo duraturo di Chamberlin è stato trasformare quel modo di pensare in un linguaggio che le persone potevano effettivamente usare.
Prima di SQL, la maggior parte delle organizzazioni non «interrogava un database». Lavoravano con dati memorizzati in file—spesso un file per applicazione—gestiti dal programma che li aveva creati. Il libro paga aveva i suoi file, l'inventario i suoi, e i record dei clienti potevano essere distribuiti su più sistemi.
Questo approccio basato sui file funzionava finché le aziende non cercavano risposte che attraversassero confini: “Quali clienti hanno comprato il prodotto X e hanno anche fatture scadute?” Ottenere quel tipo di vista significava ricucire dati che non erano pensati per essere combinati.
In molti sistemi iniziali, i formati dei dati erano fortemente legati all'applicazione. Una modifica in un punto—per esempio aggiungere un nuovo campo per il numero di telefono del cliente—poteva richiedere la riscrittura dei programmi, la conversione dei file e l'aggiornamento della documentazione. Anche quando cominciarono ad apparire «sistemi di database», molti esponevano ancora metodi di accesso a basso livello che somigliavano più a programmare che a porre domande.
Se volevi informazioni, avevi solitamente due opzioni:
Nessuna delle due opzioni favoriva l'esplorazione facile. Un piccolo cambiamento nella richiesta—aggiungere un intervallo di date, raggruppare per regione, escludere i resi—poteva trasformarsi in un nuovo compito di sviluppo. Il risultato era un collo di bottiglia: chi aveva domande doveva aspettare chi sapeva scrivere codice.
A ciò che le organizzazioni mancava era un modo condiviso per esprimere le domande sui dati—qualcosa di preciso per le macchine ma leggibile per le persone. Gli utenti di business pensano in termini di «clienti», «ordini» e «totali». I sistemi, invece, erano costruiti attorno a layout di file e a passaggi procedurali.
Questo divario creò la domanda per un linguaggio di query che potesse tradurre l'intento in azione: un modo coerente e riutilizzabile per dire cosa si vuole dai dati senza scrivere un nuovo programma ogni volta. Quella necessità preparò il terreno per la svolta di SQL.
Prima che SQL potesse esistere, il mondo dei database aveva bisogno di un modo più chiaro per pensare i dati. Il modello relazionale fornì proprio questo: un quadro semplice e coerente in cui le informazioni sono memorizzate in tabelle (relazioni), composte da righe e colonne.
La promessa centrale del modello relazionale era diretta: smettere di costruire strutture dati ad hoc e difficili da mantenere per ogni applicazione. Invece, memorizza i dati in una forma standard e lascia che programmi diversi pongano domande diverse senza riscrivere ogni volta l'organizzazione dei dati.
Questo cambiamento contava perché separava due cose che spesso erano intrecciate:
Quando queste preoccupazioni sono separate, i dati diventano più facili da condividere, più sicuri da aggiornare e meno dipendenti dalle particolarità di una singola applicazione.
Edgar F. Codd, mentre lavorava in IBM, contribuì a formalizzare questa idea e a spiegare perché era migliore rispetto alla navigazione dei record tramite percorsi fissi. Non serve una formazione accademica completa per apprezzarne l'impatto: diede all'industria un modello che si poteva ragionare, testare e migliorare.
Una volta che i dati vivono in tabelle, la domanda naturale diventa: come fanno le persone a chiedere ciò che serve? Non puntando alle posizioni di storage, ma descrivendo il risultato.
Quell'approccio «descrivi cosa vuoi»—seleziona queste colonne, filtra queste righe, collega queste tabelle—preparò il terreno per un linguaggio di query più umano. SQL fu costruito per sfruttare quel modello, trasformando la teoria relazionale in lavoro quotidiano.
IBM System R non fu inizialmente un prodotto commerciale: era un progetto di ricerca progettato per rispondere a una domanda pratica: il modello relazionale di Edgar F. Codd poteva funzionare nel mondo reale, su scala reale, con dati aziendali veri?
All'epoca molti sistemi di database venivano navigati attraverso percorsi di accesso fisici e logica riga per riga. I database relazionali promettevano qualcosa di diverso: memorizzare i dati in tabelle, descrivere chiaramente le relazioni e lasciare che il sistema capisse come recuperare i risultati. Ma quella promessa dipendeva da due elementi che dovevano funzionare insieme: un motore relazionale che rendesse bene e un linguaggio di query che sviluppatori comuni (e anche qualche non sviluppatore) potessero usare.
System R, sviluppato al San Jose Research Laboratory di IBM negli anni '70, aveva l'obiettivo di costruire un prototipo di sistema di gestione di database relazionale e mettere alla prova l'idea relazionale.
Ugualmente importante, esplorò tecniche che oggi sono fondamentali—soprattutto l'ottimizzazione delle query. Se gli utenti dovevano scrivere richieste di alto livello ("dammi questi record che soddisfano queste condizioni"), il sistema doveva tradurre automaticamente quelle richieste in operazioni efficienti.
Donald Chamberlin, lavorando nell'ambiente di ricerca di IBM, si concentrò sul pezzo mancante: un linguaggio pratico per porre domande sui dati relazionali. Insieme a collaboratori (in particolare Raymond Boyce) lavorò per definire un linguaggio di query che corrispondesse al modo naturale in cui le persone descrivono i propri bisogni di dati.
Non fu progettazione del linguaggio in isolamento. System R fornì il ciclo di feedback: se una caratteristica del linguaggio non poteva essere implementata in modo efficiente, non sopravviveva. Se una caratteristica rendeva i compiti comuni più facili, guadagnava slancio.
Codd aveva descritto il modello relazionale usando matematica formale (algebra relazionale e calcolo relazionale). Quelle idee erano potenti, ma troppo accademiche per il lavoro quotidiano. System R aveva bisogno di un linguaggio che fosse:
Quella ricerca—radicata in un prototipo relazionale funzionante—preparò il terreno per SEQUEL e poi per SQL.
Donald Chamberlin e i suoi colleghi chiamarono originariamente il nuovo linguaggio SEQUEL, abbreviazione di Structured English Query Language. Il nome era un indizio dell'idea centrale: invece di scrivere codice procedurale per navigare i dati passo passo, avresti dichiarato cosa vuoi in una forma che sembrava vicina all'inglese strutturato.
SEQUEL fu poi abbreviato in SQL (spesso per motivi pratici—più corto, più facile da stampare e pronunciare, e legato anche a considerazioni di naming e marchi). Ma l'ambizione del «structured English» rimase.
L'obiettivo di design era fare in modo che il lavoro col database somigliasse a fare una richiesta chiara:
Quella struttura diede alle persone un modello mentale coerente. Non dovevi imparare le regole di navigazione di un vendor; imparavi un modello leggibile per porre domande.
Immagina una semplice domanda di business: “Quali clienti in California hanno speso di più quest'anno?” SQL ti permette di esprimere quell'intento direttamente:
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE state = 'CA' AND order_date \u003e= '2025-01-01'
GROUP BY customer_id
ORDER BY total_spent DESC;
Anche se sei nuovo ai database, spesso puoi intuire cosa fa:
Quella leggibilità—associata a regole precise—ha aiutato SQL a diffondersi ben oltre IBM System R e nel mondo software più ampio.
Una ragione per cui SQL è rimasto è che ti permette di esprimere una domanda come la diresti ad alta voce: “Prendi queste cose, da questo posto, con queste condizioni.” Non devi descrivere come trovare la risposta passo dopo passo; descrivi cosa vuoi.
SELECT = scegli le colonne che vuoi vedere.
FROM = da quale tabella (o dataset) provengono quei dati.
WHERE = filtra le righe per mantenere solo quelle che soddisfano i criteri.
JOIN = collega tabelle correlate insieme (come far corrispondere customer_id negli ordini allo stesso customer_id nei clienti).
GROUP BY = riepiloga per categorie, così puoi parlare di totali “per cliente”, “per mese” o “per prodotto”.
SELECT customer_name, COUNT(*) AS order_count
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.status = 'Shipped'
GROUP BY customer_name;
Leggilo come: “Prendi il nome di ogni cliente e il numero di ordini, dagli ordini collegati ai clienti, mantieni solo gli ordini spediti e raggruppa per cliente.”
Se SQL ti sembra intimidatorio, fai un passo indietro e riformula il tuo obiettivo in una frase. Poi mappa le parole:
Questa abitudine «prima la domanda» è il vero design amichevole di SQL.
SQL non ha solo introdotto un nuovo modo di parlare ai dati—ha ridotto chi doveva essere «la persona del database» per ottenere risposte. Prima di SQL, porre una domanda a un database spesso significava scrivere codice procedurale, capire i dettagli dello storage o inoltrare una richiesta a un team di specialisti. Il lavoro di Chamberlin contribuì a capovolgere questa situazione: potevi descrivere cosa volevi e il database capiva come recuperarlo.
Il più grande vantaggio di accessibilità di SQL è che è sufficientemente leggibile da poter essere condiviso tra analisti, sviluppatori e team di prodotto. Anche un principiante può capire l'intento di una query come:
SELECT product, SUM(revenue)
FROM sales
WHERE sale_date \u003e= '2025-01-01'
GROUP BY product;
Non serve conoscere strutture di indice o layout di file per vedere cosa si sta chiedendo: fatturato totale per prodotto, in un intervallo di date.
Poiché SQL è dichiarativo e ampiamente insegnato, è diventato un punto di riferimento comune durante pianificazione e debug. Un product manager può verificare la domanda (“Stiamo conteggiando anche i rimborsi?”). Un analista può aggiustare le definizioni. Un ingegnere può ottimizzare le prestazioni o spostare la logica in un'applicazione o pipeline.
Ancora più importante, SQL rende la «domanda» stessa revisionabile. Può essere versionata, commentata, testata e migliorata—come il codice.
SQL semplifica il porre domande, ma non garantisce risposte affidabili. Hai comunque bisogno di:
SQL ha aperto la porta al self-service sui dati, ma buoni risultati dipendono ancora da dati di qualità e significati condivisi.
SQL non ha vinto perché fosse l'unico linguaggio di query—ha vinto perché era pratico per un'industria in crescita che aveva bisogno di abitudini condivise. Una volta che i team hanno visto che SQL permetteva di porre domande chiare sui dati senza scrivere codice personalizzato per ogni report, ha iniziato a comparire in più prodotti, formazione e offerte di lavoro.
Man mano che i vendor di database aggiungevano supporto SQL, anche altri software ne beneficiarono. Strumenti di reporting, dashboard di business intelligence e più tardi framework applicativi hanno beneficiato di avere un modo comune per recuperare e modellare i dati.
Questo creò un circuito positivo:
Anche quando i database differivano internamente, avere una «superficie» SQL familiare riduceva lo sforzo per cambiare sistema o integrare sistemi multipli.
Portabilità non significa “esegui ovunque senza modifiche”. Significa che le idee di base—SELECT, WHERE, JOIN, GROUP BY—restano riconoscibili tra i prodotti. Una query scritta per un sistema spesso necessita solo di piccole modifiche per un altro. Questo ridusse il vendor lock-in e rese le migrazioni meno spaventose.
Col tempo SQL è stato standardizzato: un insieme condiviso di regole e definizioni che i vendor in gran parte si impegnano a supportare. Pensalo come la grammatica di una lingua. Diverse regioni possono avere accenti e modi di dire, ma la grammatica di base permette la comunicazione.
Per persone e organizzazioni, quella standardizzazione ha effetti enormi:
Il risultato finale: SQL è diventato la «lingua comune» per lavorare con dati relazionali.
SQL non ha cambiato solo come si interrogano i dati—ha cambiato come si costruisce il software. Una volta che è esistito un modo comune per porre domande a un database, intere categorie di prodotti hanno potuto dare per scontato “SQL è disponibile” e concentrarsi su funzionalità di livello superiore.
Vedi SQL nelle applicazioni aziendali (CRM, ERP, sistemi finanziari), nei dashboard di reporting e dietro servizi web che recuperano e aggiornano record. Anche quando gli utenti non digitano una query, molte app generano SQL in background per filtrare ordini, calcolare totali o assemblare un profilo cliente.
Quell'ubiquità ha creato un pattern potente: se il tuo software parla SQL, può lavorare con molti sistemi di database con meno integrazione personalizzata.
Un linguaggio di query condiviso ha reso praticabile costruire strumenti che si collocano “intorno” ai database:
Il punto chiave è che questi strumenti non sono legati all'interfaccia di un singolo vendor—si affidano a concetti SQL trasferibili.
Una ragione per cui SQL conta ancora nel 2025 è che funziona come un contratto durevole tra intenzione ed esecuzione. Anche quando costruisci app con strumenti di livello superiore—o con AI—hai comunque bisogno di uno strato di database esplicito, testabile e verificabile.
Per esempio, su Koder.ai (una piattaforma vibe-coding per creare app web, backend e mobile tramite chat), i team spesso finiscono per ancorare “cosa deve fare l'app” in tabelle relazionali chiare e query SQL. Sotto il cofano, questo tipicamente significa un backend Go con PostgreSQL, dove SQL resta il linguaggio condiviso per join, filtri e aggregazioni—mentre la piattaforma accelera scaffolding, iterazione e deployment.
SQL è durato decenni, il che significa che ha accumulato anche decenni di lamentele. Molte critiche sono valide in un contesto ristretto, ma spesso vengono ripetute senza la sfumatura pratica su cui si basano i team operativi.
SQL sembra semplice quando vedi SELECT ... FROM ... WHERE ..., e poi improvvisamente appare enorme: join, raggruppamenti, window functions, common table expressions, transazioni, permessi, tuning delle performance. Quel salto può essere frustrante.
Un modo utile per inquadrarlo è che SQL è piccolo al centro e grande ai margini. Le idee centrali—filtrare righe, scegliere colonne, combinare tabelle, aggregare—si imparano in fretta. La complessità emerge quando cerchi precisione sui dati del mondo reale (valori mancanti, duplicati, fusi orari, identificatori sporchi) o quando spingi per velocità su larga scala.
Alcuna stranezza è in realtà SQL che è onesto sui dati. Per esempio, NULL rappresenta “sconosciuto”, non “zero” e non una stringa vuota, quindi le comparazioni si comportano diversamente da quanto molti si aspettano. Un'altra sorpresa comune è che la stessa query può restituire righe in ordine diverso a meno che non ordini esplicitamente—perché una tabella non è un foglio di calcolo.
Queste non sono ragioni per evitare SQL; sono promemoria che i database privilegiano correttezza e chiarezza rispetto ad assunzioni implicite.
Questa critica confonde due cose:
I vendor aggiungono funzionalità per competere e servire i loro utenti—funzioni extra, diversa gestione delle date, estensioni proprietarie, indici speciali, linguaggi procedurali. Ecco perché una query che funziona in un sistema può richiedere piccole modifiche in un altro.
Inizia padroneggiando le basi portabili: SELECT, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, e le basi di INSERT/UPDATE/DELETE. Quando ti senti a tuo agio, scegli il database che probabilmente userai di più e studiane i punti di forza (e le stranezze).
Se impari da solo, aiuta anche tenere una cheat sheet personale delle differenze incontrate. Questo trasforma “i dialetti sono fastidiosi” in “so cosa cercare”, una competenza più realistica per il lavoro quotidiano.
Imparare SQL è meno memorizzare la sintassi e più costruire un'abitudine: porre una domanda chiara, poi tradurla in una query.
Inizia con una tabella piccola (pensa: customers o orders) e fai esperienza leggendo i dati prima di provare a «fare» qualcosa.
WHERE e ORDER BY. Abituati a selezionare solo le colonne necessarie.orders + customers) usando JOIN.GROUP BY per rispondere a domande “quanto?” e “quanti?”—conteggi, somme, medie e totali mensili.Questa progressione rispecchia il modo in cui SQL è stato progettato: esprimi una domanda in parti, poi lascia che il database trovi il modo migliore per eseguirla.
Se ti eserciti su un database condiviso—o sei abbastanza nuovo da poter cliccare la cosa sbagliata—proteggiti con poche regole:
SELECT. Usalo come «modalità lettura».LIMIT 50 (o l'equivalente) così non estrai milioni di righe per errore.DELETE, UPDATE, DROP) finché non capisci bene i WHERE.SELECT della condizione WHERE per vedere quali righe verrebbero toccate.Una buona pratica SQL assomiglia a lavoro reale:
Scegli una domanda, scrivi la query e controlla se il risultato ha senso. Quel ciclo di feedback è come SQL diventa intuitivo.
Se impari SQL mentre costruisci qualcosa di concreto, aiuta lavorare in un ambiente dove schema, query e codice applicativo restano vicini. Per esempio, se prototipi una piccola app con backend PostgreSQL su Koder.ai, puoi iterare rapidamente su tabelle e query, snapshot delle modifiche ed esportare il codice sorgente quando sei pronto—senza perdere di vista la logica SQL reale.
Il contributo duraturo di Donald Chamberlin non fu solo inventare una sintassi—fu costruire un ponte leggibile tra persone e dati. SQL permise a qualcuno di descrivere cosa voleva (clienti in California, vendite per mese, prodotti con scorta bassa) senza dover spiegare come un computer doveva recuperarlo passo dopo passo. Questo cambiamento trasformò l'interrogazione dei database da un mestiere specialistico a una lingua condivisa che i team potevano discutere, revisionare e migliorare.
SQL perdura perché sta in un utile terreno di mezzo: abbastanza espressivo per domande complesse, sufficientemente strutturato da poter essere ottimizzato e standardizzato. Anche con l'arrivo di nuovi strumenti per i dati—dashboard, interfacce no-code e assistenti AI—SQL resta lo strato affidabile sotto. Molti sistemi moderni continuano a tradurre click, filtri e prompt in operazioni simili a SQL, perché i database possono verificarle, metterle in sicurezza ed eseguirle in modo efficiente.
Le interfacce cambiano, ma le organizzazioni hanno ancora bisogno di:
SQL soddisfa questi requisiti. Non è perfetto, ma è insegnabile—e quell'insegnabilità fa parte dell'invenzione.
L'eredità reale di Chamberlin è l'idea che i migliori strumenti rendono i sistemi potenti accessibili. Quando un linguaggio è leggibile, invita più persone nella conversazione—ed è così che la tecnologia si diffonde dai laboratori al lavoro quotidiano.
Donald D. Chamberlin era un ricercatore IBM che ha co-creato SQL (originariamente chiamato SEQUEL) come parte del progetto System R. Il suo contributo principale è stato contribuire a definire un linguaggio dichiarativo e leggibile, in modo che le persone potessero chiedere risultati ai database senza scrivere programmi passo dopo passo.
SQL è stato importante perché ha reso l'accesso ai dati condivisibile e ripetibile. Invece di chiedere un nuovo programma personalizzato o affidarsi a report fissi, i team potevano scrivere e revisionare query come qualsiasi altro artefatto di lavoro, accelerando l'esplorazione e riducendo i colli di bottiglia.
Un linguaggio dichiarativo dice al database qual è il risultato desiderato, non la procedura per ottenerlo. In pratica significa descrivere colonne, tabelle, filtri e raggruppamenti, e lasciare che il database scelga un piano di esecuzione efficiente (spesso tramite l'ottimizzazione delle query).
Il modello mentale di base è:
SELECT: cosa vuoi vedere (colonne o espressioni)FROM: da dove viene (tabelle/views)WHERE: quali righe qualificano (filtri)Una volta chiaro questo, puoi aggiungere per collegare tabelle, per riassumere e per ordinare.
Un JOIN combina righe di due (o più) tabelle basandosi su una condizione di corrispondenza—spesso un identificatore condiviso come customer_id. Usa i join quando le informazioni di cui hai bisogno sono distribuite su tabelle diverse (per esempio, ordini in una tabella e nomi dei clienti in un'altra).
GROUP BY ti permette di ottenere risultati “per categoria” (totali per cliente, conteggi per mese, fatturato per prodotto). Un flusso pratico è:
SELECT ... FROM ... WHERE ... che restituisca le righe giuste.COUNT(), , .System R era il prototipo di ricerca IBM degli anni '70 costruito per dimostrare che i database relazionali potevano funzionare su scala reale. Ha spinto anche idee cruciali come l'ottimizzazione delle query, che ha reso praticabile un linguaggio di alto livello come SQL permettendo al sistema di tradurre le richieste in operazioni efficienti.
SQL si è diffuso perché è diventato un'interfaccia comune tra molti database e strumenti. Questo ha creato un circuito di rinforzo:
Anche con differenze tra prodotti, i concetti di base sono rimasti riconoscibili.
I dialetti SQL esistono, ma l'approccio più efficace è:
SELECT, WHERE, JOIN, GROUP BY, , e le operazioni base di inserimento/aggiornamento.Inizia in sicurezza e costruisci a strati:
JOINGROUP BYORDER BYSUM()AVG()ORDER BYCosì le incompatibilità diventano ricerche mirate invece di frustrazioni continue.
SELECTLIMIT (o l'equivalente del tuo DB) mentre esplori.UPDATE/DELETE, esegui la stessa condizione WHERE come SELECT per vedere quali righe verrebbero modificate.L'obiettivo è tradurre domande chiare in query, non memorizzare la sintassi a memoria.