Free PlyxSQL© Beta - 1.0.0.77 - Text to SQL
POSTED , 17 LUG 2026
Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml
Configuratore semantico per il text to SQL
Perché un configuratore semantico è essenziale per il text-to-SQL su database legacy
Chi lavora con database gestionali storici — come quelli tipici della pubblica amministrazione o dei software verticali italiani — conosce bene il problema: campi chiamati IDUBICAZIONE, NGIURIDICA, STAG, tabelle con suffissi variabili come E_PUB[[ANNO]] o EREGTEMP[[ANNO]]. Nomi che hanno senso solo per chi ha scritto lo schema vent'anni fa, ma che diventano un ostacolo enorme quando si tenta di applicare un modello di linguaggio per generare SQL a partire da domande in linguaggio naturale.
Il problema dei nomi non convenzionali
Un LLM generico, senza contesto, non ha modo di sapere che NGIURIDICA = 1 significa "DITTA" o che IDCOMUNE va risolto tramite una tabella COMUNI con ref_field = ID. Senza un layer di mediazione, il modello può:
Inventare join inesistenti o sbagliare la cardinalità (confondendo relazioni 1:N con 1:1)
Interpretare male campi booleani mascherati da interi (
CHIUSO,ESENTE,PAGATO)Non riconoscere pattern di naming variabili per anno o comune, tipici di database multi-tenant o multi-periodo
Cosa fa davvero un configuratore semantico
Un configuratore semantico agisce come un dizionario vivo tra il linguaggio umano e lo schema fisico del database. Definisce esplicitamente:
Lookup e cardinalità: quali campi id vanno risolti in valori leggibili, e se il join è 1:1, 1:N o N:1 (fondamentale per evitare duplicazioni negli aggregati)
Placeholder dinamici: gestione di parametri come comune o anno che si propagano nei nomi di tabella, non solo nei valori
Campi calcolati: espressioni CASE o business logic che traducono codici interni in concetti di dominio (es.
TIPO)Filtri pre-validati: pattern di query complessi (subquery, condizioni di stato) già testati e riutilizzabili, evitando che il modello li reinventi ogni volta con margine di errore
Il valore concreto
Con questo approccio, la generazione SQL diventa deterministica e verificabile, non un'interpretazione statistica del modello. Il configuratore trasforma un database "illeggibile" in un'interfaccia semantica coerente, permettendo a chi pone la domanda — anche un utente non tecnico — di ottenere risultati corretti senza conoscere la struttura fisica sottostante.
Per chi sviluppa strumenti di code generation e automazione su schemi legacy, questo livello di configurazione non è un'opzione: è la differenza tra un text-to-SQL affidabile in produzione e un generatore di query plausibili ma potenzialmente sbagliate.
Semantic scheme
[[COMUNE]] e [[ANNO]] risolti secondo i valori di default (riccione → G911, anno → anno corrente 2026), rispettando tutti i vincoli indicati (nessun filtro su IDCOMUNE, nessuna esclusione per ESENTE, uso del filtro esatto fornito in matched_filters).Note sulla generazione
[[COMUNE]]è stato risolto inG911(Riccione), essendo il comune marcato comedefaultvalue: truein assenza di indicazioni diverse nella domanda.[[ANNO]]è stato risolto in2026, corrispondente all'anno corrente (YEAR(TODAY)), marcato come default.Nessun filtro su
ESENTEè stato applicato, coerentemente con il vincolo di non escludere questi record.Nessun filtro su
IDCOMUNEè stato inserito, come richiesto.La condizione di mora è stata ripresa integralmente dal filtro fornito in
matched_filters, senza modifiche, poiché non conteneva placeholder tra graffe da sostituire.Non sono stati inclusi JOIN verso le tabelle di
lookupspoiché la domanda "Utenti in mora" non richiede la risoluzione di alcun valore leggibile aggiuntivo (es. nome ubicazione, comune, ecc.) e nessun campo lookup è necessario per la logica di filtro.
Nessun commento:
Posta un commento