Free PlyxSQL© Beta - 1.0.0.90 - ETL
POSTED BY Giuliano pagnini, 15 AGO 2026
Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml
PlyxSQL ETL: un uragano di potenza tra le tue tabelle
Creare la query per i post del giorno nel builder su ORIGINE
In ETL selezionare NUOVA FASE
Impostare come origine la query e come destinazione POST di blogspotInserire anche la query di aggiornamento da eseguire al termine della fase
C'è un momento, in ogni progetto dati, in cui un semplice "copia da A a B" non basta più. Serve pulire un campo, tradurre un codice, combinare due colonne, decidere riga per riga cosa scrivere e cosa no, ripetere tutto ogni notte alla stessa ora senza che nessuno debba ricordarsene. È esattamente lì che entra in scena il motore ETL di PlyxSQL: non un semplice "copia dati", ma un sistema a fasi con un arsenale di regole capace di trasformare, filtrare, arricchire e sincronizzare qualunque sorgente — Firebird, SQL Server, CSV, o un connettore REST come Google Calendar — verso qualunque destinazione.
Vediamo perché, quando si scatena, è davvero un uragano.
Ogni campo mappato in una fase ETL di PlyxSQL può usare una regola diversa. Non un'unica trasformazione globale forzata su tutta la tabella: sette regole indipendenti, scelte campo per campo.
Copia il valore così com'è dalla sorgente alla destinazione. Semplice, sì, ma con una Quick Action opzionale per una pulizia last-minute senza aprire un editor di espressioni: rimuovi un simbolo di valuta, sostituisci un frammento di testo, forza maiuscolo/minuscolo, elimina gli spazi superflui. Il tocco finale prima che il valore atterri a destinazione.
2. Costante — lo stesso valore, per ogni riga
Un campo destinazione che deve sempre valere "IMPORTATO", o un flag fisso, o un codice sorgente identico su tutte le righe: la regola Costante lo scrive senza bisogno di leggere nulla dall'origine.
3. Espressione — il vero motore di trasformazione
Qui la potenza sale di livello. Un mini-linguaggio di funzioni pronte all'uso, applicabile a qualunque campo:
UPPER, LOWER, TRIM — normalizzazione testo immediataLEFT(n) / RIGHT(n) — estrazione di sottostringheDEFAULT(valore) — un paracadute per i nullCONST(valore) — un valore fisso via espressioneREGEXMATCH(pattern) — valida (o scarta) in base a un patternREGEXEXTRACT(pattern) — cattura solo ciò che serve da un testo sporcoREGEXREPLACE(pattern;sostituzione) — sostituzioni avanzate con gruppi catturati ($1, $2...)DATE(formato) — trasforma una stringa CSV in un vero TDateTimeNUMBER(decimale;migliaia) — interpreta numeri con qualunque convenzione regionaleRFC3339 — converte una data/ora reale nel formato testuale richiesto da API REST come Google Calendar (2026-08-10T14:32:07.000Z)
E per chi non vuole ricordare la sintassi a memoria, c'è un assistente visivo che elenca tutte le funzioni disponibili, i parametri richiesti, e mostra l'anteprima live del risultato.
4. Formula — quando un campo solo non basta
La regola Formula combina più campi origine in un unico valore, con segnaposto liberi tra testo e separatori:
{VIA} {NOME} → "Via Rossi"
{DATA:yyyy-mm-dd}T{ORA:hh:nn:ss}.000Z → timestamp RFC3339 per un evento calendario
Ogni segnaposto può portarsi dietro un formato specifico ({DATA:yyyy-mm-dd}), così due colonne data e ora separate diventano un unico blocco testuale pronto per qualsiasi API.
5. Lookup — la traduzione intelligente
Serve tradurre un codice cliente in ragione sociale, o un CAP in nome comune? La regola Lookup cerca il valore in un'altra tabella — origine o destinazione, a scelta — e supporta:
- chiavi composite (più campi combinati per la ricerca)
- una espressione di pulizia applicata alla chiave PRIMA della ricerca (es. estrarre "Via Emilia" da "Via Emilia, 87" con una REGEXEXTRACT mirata)
- un valore di default quando la corrispondenza non viene trovata
6. AutoIncrementale — contatori sempre coerenti
Assegna un numero progressivo a ogni riga scritta in questa esecuzione. Due modalità: si parte da un valore fisso, oppure si riparte automaticamente da MAX(campo)+1 letto dalla tabella di destinazione — mai duplicati, mai buchi da gestire a mano.
7. Ignora — il controllo è anche saper escludere
Un campo mappato ma esplicitamente escluso dalla scrittura: utile per tenere traccia della corrispondenza senza inquinare la destinazione.
Condizioni: la regola si applica solo se vuoi tu
Ogni singolo campo — qualunque sia la regola scelta — può essere subordinato a una condizione "Esegui regola solo se", con diciotto tipi di condizione pronti all'uso: vuoto/non vuoto, solo cifre, solo lettere, alfanumerico, inizia con / contiene / termina con, uguale/diverso, confronti di lunghezza testo, confronti numerici, corrispondenza a un pattern regolare — ciascuna negabile con un semplice flag.
E quando la condizione è falsa? Non un semplice "salta e basta": puoi scegliere cosa scrivere in alternativa — un valore fisso, il contenuto di un altro campo origine, o persino un'intera Formula multi-campo per il ramo "altrimenti". Una logica condizionale completa, riga per riga, senza scrivere una riga di codice.
La gestione a fasi: dove la potenza diventa struttura
Ogni fase ETL è una coppia tabella-origine → tabella-destinazione, e porta con sé un intero pannello di controllo:
- Cinque modalità di scrittura (BatchMove): Inserisci sempre, Aggiungi nuovi, Aggiorna esistenti, Aggiungi/aggiorna (upsert) ed Elimina — ognuna pensata per uno scenario diverso, dalla prima importazione alla sincronizzazione incrementale quotidiana.
- Pulizia prima dell'importazione (
ClearBefore) o SQL personalizzato eseguito prima e dopo la fase, per preparare il terreno o rifinire il risultato.
- Filtro WHERE sulla sorgente, o addirittura una query SQL personalizzata al posto della semplice tabella, per estrarre esattamente le righe che servono.
- Formati di default per fase: imposta una volta il formato data o il separatore decimale e si applica automaticamente a tutti i campi Diretto della fase, senza ripetere
DATE(...) o NUMBER(...) campo per campo.
- Connessioni per-fase: ogni fase può sovrascrivere la connessione origine/destinazione globale del progetto — utile quando un progetto ETL unico deve leggere da un database e scrivere su più destinazioni diverse (o viceversa).
- Scrittura verso il mondo reale: per le destinazioni basate su connettore (CSV, LocalSQL, REST come Google Calendar/Sheets), il motore scrive prima in una rappresentazione locale ad altissima velocità e poi effettua il "flush" reale — file o chiamata HTTP — al termine della fase, così anche migliaia di righe volano senza appesantire ogni singola scrittura di una latenza di rete.
- Diagnostica integrata: in caso di errore di scrittura, il motore confronta automaticamente i tipi di colonna della destinazione con i valori che ha provato a scrivere, e ti dice — riga per riga — la causa più probabile, invece di lasciarti un generico errore SQL da decifrare.
Il motore sotto il cofano: TFDBatchMove, dove la velocità diventa potenza
Tutto quello che abbiamo visto finora — regole, condizioni, formule — sarebbe inutile se, riga dopo riga, la scrittura fosse lenta. Ed è qui che PlyxSQL ETL fa una scelta tecnica precisa: non scrive mai una riga alla volta.
Ogni fase trasforma i dati in uno staging in memoria , e da lì un solo oggetto TFDBatchMove per fase si occupa di travasarli verso la destinazione a blocchi, usando Array DML di FireDAC invece di una ExecSQL() per singolo record. Concretamente significa che il driver non apre e chiude un'istruzione SQL per ogni riga, ma impacchetta interi lotti di righe in un'unica operazione a basso livello verso il database — lo stesso principio con cui un TIR trasporta un container invece di mille furgoncini in fila.
I numeri dietro le quinte:
- Blocchi da 500 righe di default (
CommitCount), configurabili: una singola transazione per ogni blocco scaricato, non una transazione per riga — meno overhead, meno round-trip verso il database, commit molto più rapidi.
- Un solo
TFDBatchMove per l'intera fase, non uno ricreato ad ogni blocco: l'oggetto viene semplicemente rieseguito (Execute()) più volte sullo stesso reader/writer già configurati, azzerando i costi di inizializzazione ripetuta.
- Le cinque modalità di scrittura (Inserisci sempre, Aggiungi nuovi, Aggiorna esistenti, Aggiungi/aggiorna, Elimina) girano tutte sullo stesso motore a blocchi: la potenza dell'Array DML non è riservata al semplice inserimento, ma resta piena anche negli scenari di sincronizzazione incrementale più complessi.
- Mapping automatico per nome colonna: lo staging usa già gli stessi nomi della tabella di destinazione, quindi
TFDBatchMove genera da solo INSERT/UPDATE/DELETE senza bisogno di configurazioni manuali che rallenterebbero la fase di preparazione.
- Diagnostica senza perdita di velocità: se un blocco fallisce, il motore non deve rallentare l'intera fase per capire perché — confronta i tipi delle colonne di destinazione con i valori dello staging e produce una diagnosi mirata solo sul blocco incriminato, lasciando che tutto il resto continui a correre.
Il risultato è un motore che scala: che siano 11 righe o 11 milioni, TFDBatchMove è il pistone che trasforma tutte le regole di trasformazione viste finora in scritture reali sul database — a blocchi, in transazioni compatte, con la potenza di scrittura nativa di FireDAC invece della lentezza di un ciclo riga-per-riga.
E ancora: pianificazione e assistenza AI
Un progetto ETL di PlyxSQL non deve nemmeno essere lanciato a mano ogni volta: puoi pianificarlo — giornaliero, settimanale (con giorno della settimana), o mensile (con giorno del mese, gestione automatica dei mesi corti) — e lasciarlo girare da solo.
Servizio windows gestisce tutti i progetti pianificati (a richiesta)
E se stai iniziando da zero, non serve mappare ogni campo manualmente: il motore può generare automaticamente intere fasi confrontando le tabelle omonime tra due connessioni e proponendo il mapping diretto già pronto per i campi corrispondenti — e un bridge AI opzionale può persino suggerire le corrispondenze quando i nomi dei campi non coincidono esattamente, inviando solo i nomi dei campi (mai i dati reali) al modello configurato.
Il risultato
Sette regole di campo componibili, condizioni con rami alternativi, cinque modalità di scrittura sostenute da un motore a blocchi con Array DML, filtri e SQL personalizzati, formati di default, connessioni multiple per progetto, pianificazione automatica e generazione assistita: non un semplice importatore, ma una vera centrale di trasformazione dati — capace di prendere qualsiasi sorgente e scatenarla, blocco dopo blocco, esattamente dove e come serve, alla velocità che solo TFDBatchMove può dare.
Un uragano, sì. Ma un uragano che segue esattamente le regole che gli dai.
#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL
