Da DDS a SQL, riga per riga

Un tracciato record diventa una tabella

Il DDS descrive un archivio con nome, lunghezza e decimali in colonne fisse. Sembra illeggibile e invece è regolare: è proprio questa regolarità che permette di convertirlo invece di riscriverlo a mano campo per campo.

Sorgente DDSORDHDR

SQL generatoIBM DB2

La riga che spiega tutto: CUST 5 0 significa cinque cifre e zero decimali — un numero, non un testo. È la lunghezza dichiarata nel tracciato, e da lì escono sia il tipo SQL sia la posizione del campo nel file di dati.

Non tutti i database dicono la stessa cosa

È qui che una conversione fatta a mano sbaglia. I tipi non si corrispondono uno a uno: quello che su DB2 è DECIMAL, su PostgreSQL è NUMERIC, e un INTEGER diventa INT su MySQL. Le righe evidenziate sono quelle dove il bersaglio si discosta da DB2.

Tipo AS/400	IBM DB2	PostgreSQL	MySQL	SQL Server

Perché conta su una migrazione vera: un archivio ha decine di campi e un gestionale AS/400 ne ha centinaia di archivi. Un tipo tradotto male non dà errore alla creazione della tabella — lo dà mesi dopo, quando un importo perde i decimali.

Il tracciato serve due volte

Le stesse lunghezze che generano la tabella servono anche a leggere i dati: un estratto AS/400 è un file a larghezza fissa, senza separatori. Senza il tracciato è una colonna di caratteri; con il tracciato sono righe.

Estratto a larghezza fissanessun separatore

Righe riconosciute

CUST	ORDER	ORDATE	CUSORD

Il dettaglio che fa perdere giornate: in un file a larghezza fissa non c'è niente che segnali un campo spostato di una posizione. Tutto continua a sembrare valido, e l'errore si scopre leggendo un dato che non torna. Derivare le posizioni dal tracciato invece che contarle a mano toglie di mezzo l'intera categoria di problema.

Questa è una ricostruzione con dati inventati. Su una migrazione vera i tracciati sono i vostri, e la conversione si fa in blocco da riga di comando oltre che dall'interfaccia.

Vedi la scheda prodotto