Free PlyxSQL© Beta - 1.0.0.75 - Text to SQL
POSTED , 15 LUG 2026
Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml
Configuratore semantico per il text to SQL
Dallo schema al prompt: il Configuratore Semantico di plyxSQL e le nuove Foreign Key
Se lavori con database di enti pubblici — tributi, affissioni, occupazioni di suolo — conosci bene il problema: schemi grandi, spesso non normalizzati, tabelle con nomi tag-based per comune e anno, e una crescente richiesta di "genera questa query con l'AI" da parte di chi in ufficio non scrive SQL tutti i giorni.
In questa versione dello Schema Designer di plyxSQL abbiamo aggiunto un pezzo intero dedicato esattamente a questo: il Configuratore Semantico. Non è un generatore di query — è lo strato che dice a un modello AI come leggere il tuo schema, prima ancora che scriva una riga di SQL. E già che c'eravamo, abbiamo sistemato e ampliato la gestione delle Foreign Key, che nel Designer era rimasta un po' indietro.
Vediamo cosa c'è di nuovo, con qualche esempio pratico.
Il problema di partenza
Immagina di dover chiedere a un'AI: "vorrei aggiornare le anagrafiche utenti con la PEC della tabella recapiti, solo se la PEC degli utenti è vuota". Per generare SQL corretto, l'AI ha bisogno di sapere:
- quali tabelle sono coinvolte, e con che nome reale nel DB (spesso con prefissi tipo
[[COMUNE]]e suffissi anno) - quali campi puoi davvero usare, e quali no (magari alcuni sono sensibili, o semplicemente irrilevanti)
- come si collegano due tabelle, se serve un JOIN
- quali regole di business valgono sempre ("non escludere mai i record ESENTE=1", "non filtrare per IDCOMUNE"...)
Passare tutto questo a mano, ogni volta, in un prompt scritto lì per lì, non è sostenibile. Il Configuratore Semantico lo fa una volta, dentro lo schema stesso, e da lì in poi genera il prompt corretto in automatico ad ogni domanda.
Configurare una tabella: le sei sezioni
Tasto destro su una tabella → ⚙ Configura semantica... apre un dialog con tutto quello che serve, organizzato in blocchi chiari:
1. Alias — il nome "vero" che la tabella deve avere nel prompt, placeholder inclusi: [[COMUNE]]UTENTI, [[COMUNE]]REGISTRO[[ANNO]].
2. Keyword di identificazione — le parole che, se presenti nella domanda, fanno capire all'AI (e al nostro motore di auto-detect) che questa tabella è rilevante. E qui la cosa si fa interessante: le keyword non sono semplici parole, sono espressioni booleane:
(utente+utenti+contribuente+matricola)-(insegne+occupazioni+cup)Si legge: "se la domanda parla di utenti/contribuenti, MA non di insegne, occupazioni o CUP". Supportiamo + (OR), & (AND), - (NOT) e le parentesi, con la logica booleana standard — negare un gruppo tra parentesi nega il risultato complessivo, non termine per termine. Niente sorprese, tutto prevedibile.
3. Campi attivi, con alias di dominio — scegli quali campi finiscono nel prompt (perché no, non sempre vuoi esporre tutto), e per ognuno puoi aggiungere sinonimi: il campo fisico DESCRIZIONE nella tabella VIE può avere alias ubicazione, via, indirizzo — così se la domanda usa uno di questi termini, l'AI sa a cosa si riferisce davvero, anche senza nessun JOIN.
4. Lookup — qui si dice all'AI come risolvere un ID in un valore leggibile: UTENTI.IDCOMUNE punta a COMUNI.ID, e il campo da mostrare è COMUNI.DESCRIZIONE. Due modi per configurarlo:
- a mano, in una griglia editabile;
- trascinando direttamente nel canvas da un campo all'altro (con un mini-popup che chiede quale campo mostrare);
- oppure, se hai già delle Foreign Key reali nello schema, con un click su "Importa da FK" che le legge tutte e propone i Lookup corrispondenti in automatico.
5. Campi calcolati — espressioni SQL con nome logico, tipo TIPO = CASE WHEN NGIURIDICA=0 THEN 'FISICA' ELSE 'DITTA' END.
6. Keyword filter — condizioni WHERE che scattano solo se la domanda contiene certe parole (stessa sintassi booleana della sezione 2), utile per filtri di dominio che non vuoi sempre attivi.
Le regole che valgono sempre: constraint e custom key
Tasto destro sul canvas → ⚙ Configurazione semantica globale... apre le impostazioni valide per ogni prompt generato:
- Constraint generali: una per riga, es. "non filtrare mai per IDCOMUNE", "con UNION ALL non inserire GROUP BY".
- Custom key, ora a quattro colonne — Parametro / Key / Valore / Default. Qui risolvi i placeholder:
[[COMUNE]]può avere più valori possibili (riccione → G911,gatteo → H231), e la colonna Default dice all'AI quale usare se la domanda non specifica il comune.
Genera prompt AI: dal Designer direttamente al provider
Con tutto configurato, il comando "Genera prompt AI..." (menu Query, o il pulsante dedicato in toolbar) apre una finestra dove scrivi la domanda, scegli dialetto e versione (stessa combo già nota da "Export DDL"), e ottieni il JSON pronto — o lo invii direttamente al provider AI già configurato (Anthropic, OpenAI, Ollama), senza passare da un editor esterno.
Il nostro motore di rilevamento automatico decide da solo quali tabelle includere, in base a nome e keyword — se non trova corrispondenze, include tutte le tabelle configurate e te lo segnala, non genera mai un prompt "a metà" in silenzio.
Un passo oltre: il pacchetto per il server
Il Configuratore Semantico non serve solo per generare un prompt al volo dal Designer. Con "Esporta pacchetto semantico (server)..." ottieni un JSON completo — tutte le tabelle configurate, i lookup, i campi calcolati, le constraint globali — pensato per un componente server che riceve domande a runtime e deve rigenerare da sé lo stesso tipo di prompt, senza il Designer in mezzo. Motore booleano incluso, con specifica precisa per chi deve reimplementarlo in un altro linguaggio.
Le Foreign Key, finalmente al completo
Mentre eravamo lì, abbiamo chiuso alcuni buchi storici sulle FK nel Designer:
- ON DELETE CASCADE evidenziato in rosso nel canvas — una CASCADE nascosta tra molte relazioni è un classico modo di perdere dati per errore, ora salta all'occhio anche solo scorrendo lo schema.
- Dialog "Regole FK", finalmente collegato per davvero: se hai una FK selezionata, ne modifichi ON DELETE/ON UPDATE con due semplici tendine; se parti da una tabella senza FK selezionata, si apre invece una creazione guidata — scegli il campo sorgente, la tabella di destinazione (con aggiornamento automatico dei campi disponibili) e le regole, in un colpo solo.
- Il disegno interattivo delle FK ora cattura correttamente il campo specifico da cui parti — prima, per un bug di vecchia data, finiva sempre per collegare la chiave primaria, anche se avevi trascinato da tutt'altro campo.
Produttività sul canvas
Un paio di comandi pensati per schemi grandi, dove scorrere/zoommare a mano per trovare una tabella diventa la parte più lenta del lavoro:
- Trova tabella — una combo di ricerca in alto a sinistra: scegli la tabella, e la vista si centra lì.
- Avvicina tabella — hai la tabella "attiva" selezionata e vuoi collegarci una FK verso una tabella che non è nemmeno visibile nello schema? Un click sposta quella tabella accanto a quella attiva (spostamento annullabile con Ctrl+Z, come un drag manuale), e centra la vista su entrambe.
- Le tabelle con centinaia di campi non occupano più altezze infinite di canvas: oltre una certa soglia, i campi scorrono con la rotellina — stesso comportamento già noto dal Query Builder.
- Zoom e posizione della vista vengono ora salvati con lo schema: riapri il progetto e sei esattamente dove avevi lasciato, non più tutto azzerato.
In breve
Il filo conduttore di questo giro di lavoro è uno solo: rendere lo schema autosufficiente per generare prompt AI corretti, senza che chi scrive la domanda debba conoscere i dettagli fisici del database — prefissi comune, suffissi anno, campi generici riusati con significati diversi in tabelle diverse. Tutto questo, configurato una volta nello Schema Designer, resta lì pronto per ogni nuova domanda — dal Designer stesso, o da un server che lo consulta a runtime.
Il prossimo passo naturale, su cui stiamo già ragionando, è la validazione lato server del SQL generato dall'AI prima di eseguirlo davvero — stesso principio di "non fidarsi ciecamente" applicato all'output, non solo all'input. Ne parliamo nel prossimo articolo.
