Prompt per scrivere una query SQL

Perché l’SQL generato dall’IA spesso si rompe alla prima esecuzione

Un’IA può scrivere SQL sintatticamente perfetto e consegnarti comunque una query che fallisce o, peggio, che restituisce silenziosamente numeri sbagliati. Il motivo è quasi sempre il contesto, non la competenza. Quando chiedi una query senza descrivere le tue tabelle, il modello inventa uno schema plausibile: suppone che la tua tabella utenti abbia un id e un created_at, che gli ordini si colleghino tramite user_id e che esista una colonna di stato. A volte ha ragione. Spesso la colonna in realtà è customer_id, oppure la data è memorizzata come testo, oppure non esiste alcuna colonna di stato. Il prompt qui sopra risolve la cosa alla radice imponendoti di incollare il tuo schema reale o le tue istruzioni CREATE TABLE. Una volta che il modello può vedere i nomi e i tipi di colonna reali, smette di indovinare e inizia a far corrispondere la query al tuo database.

Il dialetto non è un dettaglio

SQL è una famiglia di linguaggi, non un singolo linguaggio. Una query che funziona su PostgreSQL può fallire su MySQL perché le funzioni differiscono. La concatenazione di stringhe usa || su Postgres ma CONCAT() su MySQL. L’aritmetica delle date, LIMIT contro TOP, il supporto delle funzioni finestra e ILIKE per i confronti case-insensitive, tutto varia a seconda del motore. Ecco perché il prompt ti chiede di indicare il dialetto fin dall’inizio. Dire al modello «è BigQuery» o «è SQL Server» cambia le funzioni verso cui si orienta ed evita il frustrante ciclo di incollare un errore, ricevere una correzione e imbatterti nel problema specifico del dialetto successivo. Se non sei sicuro del tuo motore, vale la pena verificare prima di generare qualsiasi cosa, perché questo plasma ogni scelta di funzione nel risultato.

I JOIN espliciti e la gestione dei NULL separano il corretto dal plausibile

L’istruzione di usare JOIN espliciti con alias chiari punta sia alla correttezza sia alla leggibilità. Le join in stile virgola con una clausola WHERE gigantesca nascondono la logica di join e rendono facile produrre involontariamente un prodotto cartesiano. Le parole chiave esplicite INNER JOIN e LEFT JOIN costringono a enunciare la relazione con chiarezza, e scegliere tra loro conta: un inner join scarta silenziosamente le righe senza corrispondenza, quindi un report «clienti e i loro ordini» scritto con il tipo di join sbagliato escluderà silenziosamente i clienti che non hanno mai ordinato. Il requisito di gestire i NULL in modo sicuro intercetta l’altro classico trabocchetto: i confronti e le aggregazioni si comportano in modo inatteso attorno a NULL. Un filtro come WHERE status != 'closed' escluderà le righe in cui status è NULL, il che raramente è ciò che vuoi. Nominare queste preoccupazioni nel prompt fa sì che il modello ci ragioni sopra invece di prendere il percorso facile di default.

La nota sulle ipotesi è la tua rete di sicurezza

Il requisito finale — una spiegazione di una riga più ogni ipotesi — è ciò che trasforma una risposta a scatola nera in qualcosa di cui puoi fidarti. Quando il modello scrive «supponendo che ogni ordine appartenga a esattamente un cliente e che i rimborsi siano esclusi», puoi confermare o correggere quella logica immediatamente prima di eseguire qualsiasi cosa. L’ambiguità è da dove nascono i report errati, e farla emergere in linguaggio semplice costa molto meno che eseguire il debug di una query che è andata a buon fine ma ha contato la cosa sbagliata. Leggi sempre quella nota, e testa sempre la query su un piccolo campione prima di puntarla verso dati di produzione.

Perché questo prompt funziona

L’SQL dell’IA fallisce quando indovina il tuo schema o il tuo dialetto. Questo prompt fornisce entrambi più l’obiettivo esatto, così la query corrisponde alle tue tabelle reali e funziona sul tuo motore, e la nota sulle ipotesi intercetta le ambiguità prima che causino risultati errati.

Come personalizzarlo

• Incolla il tuo schema reale affinché i nomi delle colonne siano corretti.
• Indica il dialetto; le funzioni differiscono tra i database.
• Testa su un campione prima di eseguire su dati di produzione.

Variazioni di prompt da provare

Ottimizzare una query lenta esistente

Sei un ingegnere senior delle prestazioni dei database. Ecco una query SQL lenta su [database: PostgreSQL/MySQL/ecc]:
[incolla la query]
Schema e conteggi approssimativi delle righe:
[incolla tabelle, colonne, indici e conteggi delle righe]
Riscrivila perché venga eseguita più velocemente. Spiega cosa era lento (es. indice mancante, funzione su una colonna indicizzata, sottoquery inutile), suggerisci ogni indice da aggiungere e conferma che la riscrittura restituisca risultati identici. Mantieni il dialetto corretto.

Spiegare cosa fa una query

Sei un tutor di SQL. Spiega questa query [dialetto del database] in linguaggio semplice, passo dopo passo:
[incolla la query]
Descrivi cosa fa ogni JOIN, filtro e aggregazione, che aspetto ha l’insieme dei risultati, e segnala ogni caso limite o bug che noti (come la gestione dei NULL o una join che potrebbe scartare righe). Supponi che io conosca l’SQL di base ma non questa query.

Convertire una query tra dialetti

Converti questa query SQL dal [dialetto di origine] al [dialetto di destinazione]:
[incolla la query]
Sostituisci ogni funzione specifica del dialetto, gestione delle date, operazioni sulle stringhe e sintassi (come LIMIT contro TOP) con gli equivalenti corretti. Elenca ogni modifica che hai fatto e perché, e segnala tutto ciò che non ha un equivalente diretto e richiede una soluzione alternativa.

Errori comuni da evitare

• Non incollare lo schema reale. Senza i tuoi veri nomi di tabella e colonna, l’IA li inventa e la query fallisce o fa riferimento a colonne inesistenti. Incolla sempre le istruzioni CREATE TABLE o un elenco di colonne.
• Saltare il dialetto. Le funzioni differiscono tra i motori, quindi una query per un database può dare errore su un altro. Indica MySQL, PostgreSQL, SQL Server, o quello che usi davvero.
• Usare un INNER JOIN quando volevi conservare le righe senza corrispondenza. Un inner join scarta silenziosamente i record senza corrispondenza; usa un LEFT JOIN e COALESCE quando hai bisogno di ogni riga della tabella principale.
• Ignorare i NULL nei filtri. Una condizione come status != 'closed' esclude le righe in cui status è NULL. Decidi esplicitamente con IS NULL / IS NOT NULL o COALESCE.
• Fidarsi della query senza testarla. Anche l’SQL apparentemente corretto può contare la cosa sbagliata. Leggi la nota sulle ipotesi, poi eseguila su un piccolo campione prima di toccare i dati di produzione.

Domande frequenti

Ho davvero bisogno di incollare tutto il mio schema?

Perché la stessa query fallisce su MySQL ma funziona su PostgreSQL?

È sicuro eseguire in produzione SQL generato dall’IA?

L’IA può aiutarmi ad accelerare una query lenta?

Suggerimento: sostituisci le parti tra [parentesi] con le tue informazioni prima di inviare. Più sei preciso — pubblico, tono, obiettivo, vincoli — migliore sarà il risultato dell’IA.