DDS e SQL: due modi di descrivere i dati

Su IBM i un archivio si può descrivere in due modi, e il risultato è lo stesso tipo di oggetto. Un file creato con il DDS trent'anni fa è interrogabile in SQL oggi senza conversione, e una tabella creata con CREATE TABLE è leggibile da un programma RPG come qualunque file.

Non sono due database: è un database solo, con due linguaggi per descriverlo.

Il DDS

Il DDS — Data Description Specifications — è la descrizione a colonne, sorella di quella dell'RPG. Un file fisico:

     A          R ORDINIR
     A            ORDNUM         7P 0       TEXT('Numero ordine')
     A            ORDCLI        10A         TEXT('Codice cliente')
     A            ORDDAT         8P 0       TEXT('Data ordine CYYMMDD')
     A            ORDIMP        11P 2       TEXT('Importo')
     A          K ORDNUM

E un file logico, che è una vista con una chiave propria:

     A          R ORDINIR                   PFILE(ORDINI)
     A          K ORDCLI
     A          K ORDDAT

Il DDS descrive anche i file video (DSPF) e i file di stampa (PRTF), e per quelli non c'è un equivalente SQL: chi lavora su schermate 5250 continuerà a scrivere DDS comunque.

L'SQL

Lo stesso archivio, in DDL:

CREATE TABLE PRODLIB.ORDINI (
  ORDNUM  DECIMAL(7,0)   NOT NULL,
  ORDCLI  CHAR(10)       NOT NULL,
  ORDDAT  DATE           NOT NULL,
  ORDIMP  DECIMAL(11,2)  NOT NULL DEFAULT 0,
  PRIMARY KEY (ORDNUM)
);

CREATE INDEX PRODLIB.ORDINI_CLI_DATA
    ON PRODLIB.ORDINI (ORDCLI, ORDDAT);

CREATE VIEW PRODLIB.ORDINI_APERTI AS
  SELECT * FROM PRODLIB.ORDINI WHERE ORDSTA = 'A';

Le corrispondenze sono dirette: file fisico → tabella, file logico con chiave → indice, file logico con selezione → vista.

Che cosa cambia davvero

Non è una questione di gusto. Ci sono tre differenze concrete.

I vincoli. L'SQL permette di dichiarare chiavi primarie, chiavi esterne, unicità e condizioni di validità, e il database le fa rispettare a chiunque scriva — programma vecchio, programma nuovo, connessione ODBC. In DDS quelle regole stanno nei programmi, e valgono finché tutti passano dai programmi.

I tipi. L'SQL ha DATE, TIME, TIMESTAMP e i tipi variabili. Il DDS lavora con numerici e alfanumerici, ed è il motivo per cui su questa piattaforma si trovano date scritte come numeri a sette cifre: non c'era altro modo. Una colonna DATE non può contenere il 31 febbraio; un 7P 0 sì.

Quello che sa l'ottimizzatore. Le tabelle SQL portano con sé informazioni che il DDS non ha, e su tabelle definite in SQL l'ottimizzatore lavora meglio. Su archivi grandi la differenza si misura.

Come si legge, che è un'altra scelta ancora

Descrivere i dati in un modo o nell'altro è indipendente dal come li si legge in un programma. Le due strade convivono anche dentro lo stesso programma.

Lettura nativa a record. CHAIN, READ, SETLL, READE: si prende un record alla volta seguendo una chiave. È veloce quando si sa esattamente quale record serve, ed è il modo in cui è scritto tutto il codice storico.

SQL incorporato. Si dichiara che cosa si vuole e il database decide come prenderlo. È di gran lunga migliore quando si lavora su insiemi — totali, raggruppamenti, join, filtri complessi — e su questo la lettura a record non è competitiva, perché un join fatto a mano in RPG è un ciclo dentro un ciclo.

Che cosa fare con l'esistente

La risposta breve è: non convertire per convertire.

Il codice non va toccato. Un programma RPG che legge ORDINI continua a funzionare identico se ORDINI diventa una tabella SQL, purché i campi restino gli stessi. La conversione della definizione non è una riscrittura dell'applicativo.

I nuovi archivi si fanno in SQL. È la scelta a costo zero: da oggi in avanti, quello che si crea si crea in DDL. Nessuna migrazione, nessun rischio, e il vantaggio si accumula.

Gli indici sì, subito. Non c'è nessun motivo di descrivere in DDS un nuovo file logico di sola chiave: CREATE INDEX fa la stessa cosa, e il sistema stesso dice quali indici vorrebbe.

SELECT TABLE_NAME, KEY_COLUMNS_ADVISED, TIMES_ADVISED
  FROM QSYS2.SYSIXADV
 WHERE TABLE_SCHEMA = 'PRODLIB'
 ORDER BY TIMES_ADVISED DESC