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 è 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         7P 0       TEXT('Data ordine CYYMMDD')
     A            ORDIMP        11P 2       TEXT('Importo')
     A            ORDSTA         1A         TEXT('Stato: A aperto')
     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,
  ORDSTA  CHAR(1)        NOT NULL DEFAULT 'A',
  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, e quando si controllano. Anche il DDS ha la data, l'ora e il timestamp (tipi L, T e Z), ma molti archivi tengono le date in campi numerici, come il 7P 0 qui sopra, e un 7P 0 può contenere il 31 febbraio, una colonna DATE no. C'è poi una differenza che tocca tutti i tipi: IBM spiega che un file fisico non impone i tipi con la stessa forza di una tabella SQL, e che un programma che scrive a record può mettere in un campo impaccato dati non validi; in una tabella SQL una scrittura così viene rifiutata.

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 senza ricompilazione se ORDINI diventa una tabella SQL con lo stesso identificativo di livello del formato: il Redbook IBM sulla modernizzazione chiede di controllarlo dopo la conversione. La conversione della definizione non è una riscrittura dell'applicativo, e l'SQL di partenza lo genera ACS (Schemi, «Generate SQL») o il servizio GENERATE_SQL.

I nuovi archivi si fanno in SQL. È la scelta a costo zero: da oggi in avanti, quello che si crea si crea in DDL.

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, MTI_USED
  FROM QSYS2.SYSIXADV
 WHERE TABLE_SCHEMA = 'PRODLIB'
 ORDER BY MTI_USED DESC, TIMES_ADVISED DESC

Non crearli tutti. L'advisor ragiona una query alla volta: non sa quali indici hai già, quante scritture prende quella tabella, né che metà dei consigli sono varianti dello stesso. Ogni indice va mantenuto a ogni INSERT, UPDATE e DELETE, e una tabella caricata di indici inutili rallenta i batch notturni, con il sintomo che compare settimane dopo, lontano da chi li ha creati. Un indice su (A, B, C) copre già le ricerche per (A) e (A, B), quindi tre consigli sono spesso un indice solo. Come si leggono i consigli e come si consolidano sta nella ricetta trovare gli indici che il sistema consiglia.

Fonti

• IBM: Data type for physical and logical files
• IBM Redbook: Modernizing IBM i Applications, cap. 9, Database re-engineering