PlyxSQL 111: il nuovo SQL Manager cross-database per sviluppatori professionisti
PlyxSQL v30 rappresenta una nuova importante evoluzione di un ambiente SQL progettato per lavorare con database differenti attraverso un'unica piattaforma.
La nuova versione introduce una revisione architetturale profonda che coinvolge gestione delle connessioni, SQL Builder, SQL Editor, Schema Designer, generazione DDL, capability SQL, versioni dei database e test di compatibilità.
L'obiettivo è ambizioso: offrire agli sviluppatori un ambiente nel quale la generazione SQL non dipenda semplicemente dal nome del database, ma dal contesto reale del server e dalle funzionalità effettivamente disponibili.
Un unico ambiente per database differenti
Uno dei problemi più complessi nello sviluppo di strumenti SQL multi-database è rappresentato dalle differenze tra i vari dialetti.
Una query valida su PostgreSQL potrebbe non essere valida su SQL Server.
Una sintassi disponibile su MySQL 8 potrebbe non essere disponibile su MySQL 5.7.
MariaDB e MySQL possono condividere molta sintassi, ma non sono sempre equivalenti.
DB2, Informix e Microsoft Access introducono inoltre numerose peculiarità specifiche.
PlyxSQL v30 affronta questo problema con una nuova architettura basata sul concetto di SQL Workspace.
SQL Workspace: il cuore della nuova architettura
Il nuovo TSQLWorkspaceContext raccoglie in un unico contesto tutte le informazioni necessarie alla gestione SQL.
Il Workspace comprende:
connessione;
dialetto SQL;
prodotto;
versione del server;
origine delle informazioni;
sessione SQL;
capability;
generazione del contesto.
Il vantaggio è importante: Builder, Editor, Designer e altre funzionalità possono lavorare sullo stesso contesto SQL.
L'architettura può essere rappresentata così:
Connessione
│
▼
Tree Explorer
│
▼
SQL Workspace Context
│
┌───┼───────────────┐
▼ ▼ ▼
Builder Editor Schema Designer
│
▼
SQL / DDL
Questa struttura riduce drasticamente il rischio che componenti differenti utilizzino informazioni diverse sul database attivo.
Database, prodotto e versione: una distinzione fondamentale
PlyxSQLv30 introduce una gestione più precisa dell'identità del database.
Non viene considerato soltanto il semplice dialetto.
Il sistema distingue tra:
Dialect
Product
Server Version
Session
Capabilities
Questa distinzione è fondamentale per gestire correttamente database come MySQL e MariaDB.
MySQL e MariaDB finalmente distinti
MySQL e MariaDB condividono moltissima sintassi, ma non sono lo stesso prodotto.
La v30 introduce quindi una gestione esplicita del prodotto.
Questo permette al sistema di sapere che una connessione utilizza:
Dialect: MySQL
Product: MariaDB
quando questa è la rappresentazione sintattica più appropriata.
Il risultato è una base molto più solida per gestire le differenze specifiche dei due database.
AutoDetect più affidabile
La funzione di autodetection è stata migliorata per evitare che il rilevamento automatico sovrascriva arbitrariamente le impostazioni definite manualmente.
Il sistema può utilizzare informazioni provenienti da:
driver;
server;
progetto;
configurazione manuale.
La scelta manuale dell'utente viene quindi rispettata.
Questo rende il comportamento molto più prevedibile quando si lavora con configurazioni particolari o database legacy.
Capability Engine: sapere cosa può realmente fare il database
Una delle innovazioni architetturali più importanti della v30 è il nuovo sistema centralizzato delle SQL Capability.
Il progetto dispone ora di un Core che descrive le funzionalità supportate dai vari database.
Tra queste troviamo:
Foreign Key;
Check Constraint;
Views;
Triggers;
Routines;
Sequences;
Lateral;
Apply;
Returning;
Generated Columns;
JSON;
Pagination;
altre funzionalità specifiche.
Il Builder può quindi basare la generazione SQL sulle funzionalità disponibili invece di utilizzare esclusivamente controlli basati sul nome del database.
Perché le Capability sono così importanti?
Consideriamo un esempio.
Non è sufficiente sapere:
Database = SQL Server
Bisogna sapere anche:
SQL Server
+
versione
+
sessione
+
feature disponibili
Una funzionalità può infatti essere stata introdotta soltanto in una determinata versione.
Per questo PlyxSQL v30 considera la versione del server come parte integrante del contesto SQL.
Server Profile
Il SQL Builder utilizza un profilo server più completo attraverso il concetto di:
TSQLServerProfile
Il profilo combina:
dialetto;
prodotto;
versione;
capability;
sessione.
Questo permette al generatore SQL di prendere decisioni molto più precise.
Il risultato è un Builder più consapevole dell'ambiente nel quale sta operando.
SQL Builder più intelligente
Il Builder è stato profondamente migliorato nella gestione delle funzioni SQL.
In particolare sono stati introdotti contratti espliciti per le funzioni scalari.
Una funzione può essere:
nativa;
emulata;
non supportata;
dipendente dalla versione.
Questo è molto più sicuro rispetto a supporre che una funzione con lo stesso nome abbia necessariamente lo stesso comportamento su tutti i database.
Supporto specifico per DB2
DB2 presenta numerose particolarità sintattiche.
La v30 introduce un renderer specifico per le funzioni scalari DB2.
Questo consente di gestire in modo dedicato funzioni relative a:
stringhe;
lunghezza;
substring;
padding;
funzioni numeriche.
Il Builder non deve quindi trattare DB2 semplicemente come una variante generica dello standard SQL.
Supporto specifico per Informix
Anche Informix dispone di una gestione dedicata per le funzioni scalari.
Questa scelta consente di produrre SQL maggiormente aderente alle caratteristiche del database.
È un passaggio importante per un prodotto che vuole supportare realmente anche database meno diffusi rispetto ai classici MySQL, PostgreSQL e SQL Server.
Supporto specifico per Microsoft Access
Microsoft Access rappresenta un ambiente particolarmente diverso rispetto ai database server tradizionali.
La v30 introduce una gestione specifica delle sue funzioni SQL e delle sue peculiarità.
Questo permette di evitare di utilizzare automaticamente la sintassi dei database server-oriented.
Pagination cross-database
La gestione della paginazione SQL è stata resa più robusta.
Sono stati affrontati in particolare:
offset negativi;
overflow;
conversione dei valori;
differenze tra database;
sintassi specifiche dei vari dialetti.
La generazione della paginazione viene quindi effettuata tenendo conto delle caratteristiche del database.
Quoting degli identificatori
Il quoting è un'altra area particolarmente delicata in un ambiente SQL multi-database.
PlyxSQLv30 dispone di una gestione più strutturata del quoting.
Questo consente di tenere conto delle differenze tra:
SQL Server;
PostgreSQL;
MySQL;
MariaDB;
Firebird;
InterBase;
Access;
altri dialetti supportati.
Il quoting viene quindi trattato come una caratteristica del contesto SQL e non come una semplice operazione testuale.
DDL: una nuova architettura unificata
La gestione del DDL è stata completamente riorganizzata.
La v30 introduce una struttura composta da:
SQL DDL Service
DDL Generator
SQL DDL IR
L'utilizzo di un modello intermedio consente di separare la descrizione dell'oggetto dalla sintassi specifica del database.
Questo rende la generazione DDL più facilmente estendibile.
DDL coerente tra Tree e Designer
Una delle migliorie più importanti è la maggiore uniformità tra le operazioni effettuate dal Tree Explorer e quelle effettuate dallo Schema Designer.
La stessa architettura DDL viene utilizzata per le diverse modalità operative.
Questo riduce il rischio di avere:
SQL differente a seconda del punto dell'applicazione dal quale viene eseguita la stessa operazione.
Foreign Key, Index e Constraint
La gestione degli oggetti strutturali del database è stata migliorata.
Particolare attenzione è stata dedicata a:
Foreign Key;
Index;
Constraint;
Check Constraint;
quoting;
nomi degli oggetti;
riferimenti tra tabelle;
differenze DDL tra database.
La capability matrix permette inoltre di distinguere meglio ciò che un database può realmente eseguire.
Trigger più accurati
La gestione dei trigger è stata resa più precisa.
In particolare vengono considerate le differenze relative ai trigger:
INSTEAD OF
che non sono disponibili allo stesso modo in tutti i database.
Questo evita di trattare tutte le implementazioni dei trigger come equivalenti.
Routine e cataloghi database
La gestione delle routine è stata migliorata attraverso una classificazione più precisa degli oggetti restituiti dai cataloghi database.
Questo consente di distinguere meglio:
procedure;
funzioni;
routine;
differenti tipologie catalogate dai vari DBMS.
Il Tree Explorer può quindi rappresentare gli oggetti in modo più coerente.
SQLite e le sue particolarità DDL
SQLite non dispone dello stesso modello DDL dei database server tradizionali.
La v30 gestisce esplicitamente le limitazioni relative alle constraint e alle operazioni DDL.
In particolare vengono evitate operazioni che SQLite non può eseguire direttamente con la stessa modalità di altri database.
SQL Script Runner
La gestione degli script SQL è stata centralizzata attraverso il nuovo:
SQLScriptRunner
Il sistema gestisce:
analisi;
suddivisione;
pianificazione;
esecuzione;
gestione degli errori.
Questo permette di avere una pipeline SQL più coerente.
SQL Script Splitter
La suddivisione degli script è stata migliorata per gestire correttamente le singole istruzioni.
Questo è particolarmente importante quando uno script contiene strutture SQL più complesse.
La separazione tra parsing dello script e sua esecuzione permette inoltre di migliorare progressivamente il motore senza dover modificare tutte le funzionalità che utilizzano SQL.
Esecuzione DDL asincrona
Le operazioni DDL possono essere eseguite attraverso un modello asincrono.
Questo è fondamentale per database:
remoti;
lenti;
con molti oggetti;
soggetti a lock;
con operazioni DDL lunghe.
L'interfaccia può quindi rimanere reattiva durante le operazioni più pesanti.
SQL Execution Matrix
Una delle funzionalità più interessanti della v30 è la:
SQL Execution Matrix
Non ci si limita a verificare che il Builder produca una stringa.
Le query possono essere eseguite realmente sul database.
La matrice verifica attualmente diverse categorie, tra cui:
funzioni scalari;
quoting;
pagination;
coerenza del dialetto.
Questo introduce un concetto molto importante:
testare SQL realmente eseguibile e non soltanto SQL apparentemente corretto.
Dal test statico al test reale
Un SQL Builder può produrre una query apparentemente perfetta:
SELECT ...
ma soltanto il database può confermare se quella query è realmente valida.
La SQL Execution Matrix introduce quindi una verifica concreta del comportamento del generatore.
È un passo fondamentale verso un ambiente SQL professionale.
Sincronizzazione Tree Explorer, Builder ed Editor
La v30 migliora il collegamento tra i tre componenti principali:
Tree Explorer
Gestisce le connessioni e il Workspace.
SQL Builder
Genera SQL sulla base del Workspace.
SQL Editor
Visualizza e modifica il codice SQL.
Il flusso diventa quindi:
CONNESSIONE
↓
TREE EXPLORER
↓
WORKSPACE
↓
BUILDER
↓
SQL
↓
EDITOR
Questo rende l'interazione tra i componenti molto più prevedibile.
SQLManagerMenu come orchestratore
SQLManagerMenu rimane il centro operativo dal quale vengono avviate numerose funzioni.
La nuova architettura, però, riduce progressivamente la quantità di logica duplicata all'interno del menu.
Il menu coordina le operazioni mentre il Workspace e i servizi specializzati gestiscono le informazioni SQL.
Questa separazione rende il progetto più facilmente manutenibile.
Cache e invalidazione del contesto
La gestione della cache è stata integrata con il concetto di generazione del Workspace.
Quando cambia il contesto della connessione, le informazioni precedenti possono essere invalidate.
Questo è particolarmente importante quando l'utente passa rapidamente tra database differenti.
Ad esempio:
PostgreSQL
↓
SQL Server
↓
Firebird
↓
MariaDB
senza riavviare l'applicazione.
Gestione delle versioni server
La versione del server è diventata una componente importante del modello SQL.
Questo consente di gestire meglio le differenze tra:
MySQL 5.7
MySQL 8.x
oppure:
SQL Server legacy
SQL Server moderno
e analogamente per gli altri DBMS.
Questa impostazione è fondamentale per evitare che il Builder consideri automaticamente tutte le versioni di un database equivalenti.
Una vera architettura Cross-Dialect
La v30 non si limita quindi a tradurre:
SQL standard → SQL database
L'approccio è più evoluto:
Workspace
↓
Dialect
↓
Product
↓
Version
↓
Session
↓
Capabilities
↓
Renderer
↓
SQL
Questo rappresenta un modello molto più vicino a un vero SQL compiler/generator cross-database.
Perché la v30 è importante
La vera innovazione della versione 30 non è una singola funzione.
È il modo in cui le diverse funzionalità sono state collegate.
La piattaforma dispone ora di una catena architetturale molto più coerente:
Connection → Workspace → Capability → Renderer → SQL → Execution
Questo permette di costruire in futuro funzionalità ancora più sofisticate senza dover duplicare continuamente la logica per ogni database.
I database supportati
L'architettura v30 è progettata per lavorare con numerosi DBMS, tra cui:
Firebird;
InterBase;
PostgreSQL;
MySQL;
MariaDB;
Microsoft SQL Server;
Oracle;
SQLite;
IBM Db2;
Informix;
Microsoft Access.
Il valore dell'architettura sta proprio nella capacità di gestire le differenze tra questi ambienti mantenendo un modello comune.
PlyxSQL v30 rappresenta una delle evoluzioni architetturali più importanti del progetto.
Il passaggio fondamentale è quello da una gestione SQL basata principalmente sul semplice dialetto a una gestione basata sul contesto completo:
Database + Product + Version + Session + Capability + Renderer
Questo approccio permette di affrontare in modo molto più professionale la complessità del mondo SQL.
Il Builder non deve più semplicemente chiedersi:
"Quale database sto utilizzando?"
ma deve poter rispondere a una domanda molto più precisa:
"Quale sintassi SQL è realmente disponibile in questo specifico ambiente?"
È questa filosofia che rende la v30 una piattaforma particolarmente interessante per lo sviluppo di applicazioni database multi-DBMS.
Nessun commento:
Posta un commento