Scrivere query SQL con un assistente AI può far risparmiare tempo, ma c’è un problema ricorrente: il modello spesso produce codice plausibile, non sempre codice corretto. È qui che gli esempi prompt engineering per sviluppare codice SQL diventano davvero utili. Un buon prompt non serve solo a “farsi scrivere una query”, ma a ridurre ambiguità, prevenire errori logici e ottenere istruzioni adatte al database reale che si sta usando.
Per chi lavora tra report, esportazioni, dashboard e troubleshooting applicativo, il punto non è usare l’AI in modo spettacolare. Il punto è usarla in modo affidabile. In SQL, una piccola imprecisione può alterare risultati, rallentare il server o – nel peggiore dei casi – toccare dati che non dovevano essere modificati.
Perché il prompt engineering conta davvero in SQL
Quando si chiede a un modello di generare SQL, il sistema non conosce automaticamente schema, vincoli, nomi reali delle colonne, convenzioni interne o dialetto del database. Se il prompt è generico, la risposta tende a riempire i vuoti con supposizioni. E in SQL le supposizioni costano caro.
La differenza tra un prompt debole e uno ben costruito si vede subito. Un prompt debole è del tipo: “scrivi una query per vedere le vendite del mese scorso”. Sembra chiaro, ma mancano dettagli essenziali: quale tabella? Quale campo data? Vendite concluse o solo ordini creati? Serve il totale per cliente, per giorno o per prodotto? Il database è MySQL, PostgreSQL o SQL Server?
Un prompt forte, invece, delimita il problema. Specifica obiettivo, tabelle, relazioni, output atteso, filtri, dialetto SQL e persino cosa evitare. Più il contesto è aderente all’ambiente reale, meno lavoro di correzione servirà dopo.
Come strutturare prompt efficaci per SQL
Il modo più pratico per costruire prompt utili è trattarli come mini-specifiche tecniche. Non serve scrivere testi lunghi per forza, ma serve essere precisi. In genere funzionano bene cinque elementi: contesto del database, obiettivo della query, schema coinvolto, formato dell’output e vincoli.
Un prompt utile può suonare così:
“Genera una query PostgreSQL per ottenere il totale fatturato per cliente negli ultimi 90 giorni. Usa la tabella ordini con colonne id_ordine, id_cliente, data_ordine, importo_totale, stato. Considera solo stato = ‘confermato’. Restituisci id_cliente, numero_ordini, totale_fatturato. Ordina per totale_fatturato decrescente. Non usare CTE se non necessarie.”
Qui il modello ha abbastanza informazioni per produrre qualcosa di vicino al bisogno reale. Se si vuole fare un passo in più, si può chiedere anche una breve spiegazione della logica usata e dei possibili limiti.
Esempi prompt engineering per sviluppare codice SQL in casi reali
Generare una SELECT semplice ma corretta
Per query basilari, l’errore tipico è ottenere campi sbagliati o filtri troppo generici. Un prompt essenziale ma ben orientato può essere:
“Scrivi una query MySQL per estrarre nome, cognome ed email degli utenti registrati negli ultimi 30 giorni dalla tabella utenti. Colonne disponibili: id, nome, cognome, email, data_registrazione, stato_account. Includi solo stato_account = ‘attivo’. Ordina per data_registrazione decrescente.”
Questo prompt funziona perché evita di chiedere una generica “lista utenti recenti”. Il modello conosce struttura minima, filtro corretto e ordinamento richiesto.
Costruire JOIN senza confondere le relazioni
Le JOIN sono uno dei punti in cui l’AI tende a inventare chiavi o relazioni non dichiarate. Qui conviene esplicitare sempre i legami.
Esempio:
“Genera una query SQL Server che unisca clienti e ordini. Tabelle: clienti(id_cliente, ragione_sociale, settore), ordini(id_ordine, id_cliente, data_ordine, totale, stato). Obiettivo: mostrare ragione_sociale, numero di ordini e totale cumulato per ogni cliente con almeno un ordine nel 2024. Considera solo ordini con stato = ‘evaso’. Usa INNER JOIN e GROUP BY corretti.”
Il dettaglio “usa INNER JOIN e GROUP BY corretti” non è ridondante. Aiuta il modello a non produrre SELECT aggregate con colonne non raggruppate, errore frequente soprattutto quando il prompt resta vago.
Tradurre una richiesta di business in SQL
Molti utenti non ragionano subito in tabelle ma in esigenze operative. In quel caso il prompt deve colmare il passaggio tra linguaggio business e query tecnica.
Un buon esempio è questo:
“Devo identificare i prodotti mai venduti negli ultimi 180 giorni. Database PostgreSQL. Tabelle: prodotti(id_prodotto, nome_prodotto, attivo), righe_ordine(id_riga, id_ordine, id_prodotto, quantita), ordini(id_ordine, data_ordine, stato). Considera vendite valide solo per ordini con stato = ‘pagato’. Restituisci id_prodotto e nome_prodotto dei prodotti attivi senza vendite nel periodo. Preferisci NOT EXISTS invece di NOT IN.”
Qui il prompt contiene anche una scelta tecnica. Chiedere NOT EXISTS può evitare problemi con valori NULL che in alcuni scenari rendono NOT IN meno affidabile.
Prompt per debugging e correzione di query SQL
Una delle applicazioni più utili non è generare SQL da zero, ma correggere query che già esistono. In questo caso, il prompt migliore non chiede solo “trova l’errore”, ma fornisce sintomo, obiettivo e query attuale.
Esempio:
“Analizza questa query MySQL e correggila mantenendo lo stesso obiettivo. Obiettivo: ottenere il totale ordini per mese nel 2024. Problema attuale: restituisce duplicati. Spiega in 4-5 righe perché accade e proponi una versione corretta. SELECT c.nome, o.data_ordine, SUM(o.totale) FROM clienti c JOIN ordini o ON c.id_cliente = o.id_cliente WHERE YEAR(o.data_ordine) = 2024 GROUP BY o.data_ordine;”
Questo approccio è molto più utile di una semplice rigenerazione. Permette di usare l’AI come supporto tecnico, non solo come generatore automatico. Per chi gestisce report o query legacy, è spesso il caso d’uso più concreto.
Chiedere query sicure: attenzione a UPDATE e DELETE
Quando il prompt riguarda modifiche dati, serve un livello di cautela superiore. Se si chiede un UPDATE o un DELETE senza paletti, il rischio è ottenere istruzioni troppo aggressive o poco verificabili.
Meglio impostare il prompt così:
“Scrivi una query SQL Server per aggiornare lo stato degli ordini da ‘in_attesa’ a ‘annullato’ solo per record più vecchi di 60 giorni. Prima della query finale, mostra una SELECT di verifica con gli stessi filtri. Non usare query distruttive senza clausola WHERE. Aggiungi un commento che ricordi di eseguire un backup o una transazione di test.”
Questo tipo di richiesta è adatto a un contesto operativo serio. Non elimina il bisogno di controllo umano, ma introduce una disciplina utile. In ambienti di produzione, ogni modifica dovrebbe essere verificata prima in staging o almeno all’interno di una transazione reversibile.
Un’avvertenza che vale sempre
Se il modello propone una query di aggiornamento o cancellazione, non eseguirla mai alla cieca. Verifica schema, numero di righe coinvolte e condizioni WHERE. Una query formalmente corretta può comunque essere sbagliata per il tuo database.
Migliorare prestazioni e leggibilità con il prompt engineering
Un altro scenario utile riguarda l’ottimizzazione. Se una query funziona ma è lenta, il prompt deve includere non solo il testo della query ma anche informazioni sul volume dati e sugli indici presenti.
Esempio:
“Ottimizza questa query PostgreSQL per una tabella ordini con circa 5 milioni di record. Obiettivo: ridurre i tempi di esecuzione senza cambiare il risultato. Indici esistenti: idx_ordini_data_ordine su data_ordine, idx_ordini_id_cliente su id_cliente. Suggerisci anche se conviene riscrivere la query o aggiungere un indice composito.”
In questo caso l’AI può dare buoni spunti, ma non va trattata come sostituto del piano di esecuzione. Le proposte vanno sempre validate con EXPLAIN o strumenti equivalenti del motore database in uso. È una distinzione importante: il modello aiuta a formulare ipotesi, non certifica prestazioni reali.
Gli errori più comuni nei prompt SQL
Molti problemi nascono da richieste troppo sintetiche. Se manca il dialetto SQL, il modello potrebbe usare funzioni incompatibili. Se manca lo schema, può inventare colonne. Se manca l’obiettivo esatto, può restituire una query corretta dal punto di vista sintattico ma inutile sul piano operativo.
Un altro errore frequente è chiedere troppe cose insieme. Per esempio: generare query, documentarla, ottimizzarla, convertirla da MySQL a PostgreSQL e aggiungere test in un solo prompt. In questi casi spesso la qualità cala. Funziona meglio un approccio per passaggi: prima la query, poi la revisione, poi l’ottimizzazione.
C’è poi il problema della fiducia eccessiva. Una risposta sicura non equivale a una risposta giusta. Vale soprattutto con funzioni data, aggregazioni, sottoquery correlate e gestione dei NULL, dove piccole differenze cambiano il risultato finale.
Un metodo pratico per ottenere risultati migliori
Se vuoi usare bene l’AI per SQL, conviene adottare un flusso semplice. Prima descrivi database e obiettivo. Poi chiedi la query. Dopo, chiedi una revisione critica: “quali assunzioni hai fatto?” Infine, verifica tu stesso sintassi, logica, cardinalità e impatto.
Per molti utenti home office o professionisti SMB, questo è già sufficiente per trasformare uno strumento generico in un supporto davvero operativo. Anche su supportotecnico.ai, l’approccio più utile resta questo: ridurre gli errori prima che diventino blocchi di produttività.
Gli esempi prompt engineering per sviluppare codice SQL funzionano quando trattano il modello come un assistente da guidare, non come un motore infallibile. Più il prompt somiglia a una richiesta tecnica ben fatta, più la risposta tende a essere utile, verificabile e pronta per il lavoro vero.
