Ultimo aggiornamento: 16-Mar-2019

12 Settembre 2017MarkOne

System naming vs SQL naming

Quando si esegue una istruzione SQL è importante impostare il naming (ovvero “convenzione di denominazione”) corretto.

Cosa significa corretta? Dipende dal risultato che si vuole ottenere, quindi bisogna conoscere le differenze tra i due naming: system (*SYS) o SQL (*SQL).

Alcune differenze sono di carattere di nomenclatura, altre di sintassi e altre ancora (le più importanti a cui prestare attenzione) riguardano le autorizzazioni che verranno assegnate all’oggetto creato.

La convenzione di denominazione è una proprietà del driver JDBC/ODBC oppure una proprietà della sessione script SQL (strsql).

Molto sinteticamente si può dire che con il system naming il comportamento che si ottiene è paragonabile a quello che si otterrebbe utilizzando i comandi di sistema operativo (CRTLIB, CRTPF….). Invece l’SQL naming è conforme alle regole dello standard SQL comune a tutti i database.

Terminologia

Innanzitutto tra le due convenzioni esiste una differenza nei nomi con cui si identificano i vari tipi di oggetti.

La figura seguente mostra il parallelismo indicando brevemente il comando che si usa per generare l’oggetto.

Naming default

Eseguendo le istruzioni SQL da diversi ambienti si può avere una convenzione di denominazione di default diverse.

Siccome le differenze più importanti tra i due naming riguarda la creazione degli oggetti, è bene controllare quale convenzione si stia adottando. Soprattutto nel caso in cui lo script SQL venga eseguito a volte p.es. utilizzando l’interfaccia STRSQL da 5250 oppure altre volte usando client SQL su PC che si collegano a IBM i tramite driver JDBC. In quest’ultimo caso la convenzione di denominazione di default è *SQL e quindi l’oggetto creato avrà proprietà diverse rispetto a quelli creati tramite STRSQL.

Assegnazione proprietario e autorizzazioni per gli oggetti di database

Questo capitolo è da leggere con attenzione perché l’assegnazione del proprietario e le autorizzazioni degli oggetti di database creati hanno parecchie differenze.

Con la convenzione di denominazione *SYS si ottiene un risultato analogo come se si creasse l’oggetto con i comandi “tradizionali” del sistema operativo (CRTLIB, CRTPF, CRTLF…) da un sorgente scritto con le DDS.

Nella figura seguente questo comportamento è evidenziato nel riquadro a sinistra *SYS naming.

Quindi se ci si trova in un ambiente misto dove i sorgenti degli oggetti di database sono scritti sia con DDS sia con SQL, al fine di mantenere un risultato uniforme sarebbe opportuno adottare la convenzione di denominazione *SYS.

NOTA BENE: con la convezione di denominazione SQL bisogna porre attenzione anche al caso in cui si stia creando uno schema o un oggetto all’interno di uno schema il cui nome corrisponde con un nome di profilo utente esistente su IBM i. Nella figura seguente questo caso è sintetizzato nel riquadro a destra *SQL naming seguendo la freccia blu

Assegnazione proprietario e autorizzazioni per procedure/funzioni/trigger

Così come per gli oggetti di database (illustrati al paragrafo precedente) anche per le procedure/funzioni e trigger SQL esistono delle differenze nell’assegnazione del proprietario e delle autorizzazioni agli oggetti creati.

NOTA BENE: con la convezione di denominazione SQL bisogna porre attenzione anche al caso in cui si stia creando un oggetto all’interno di uno schema il cui nome corrisponde con un nome di profilo utente esistente su IBM i.

Schema di default

Anche l’impostazione del default schema merita una particolare attenzione.

Innanzitutto bisogna chiarire un facile equivoco: current schema (concetto del mondo SQL) è diverso da libreria corrente (concetto del mondo del sistema operativo).

Impostare in una sessione di lavoro SQL il current schema non equivale a impostare la libreria corrente, anche se in prima istanza i risultati ottenuti eseguendo le istruzioni SQL potrebbero sembrare equivalenti.

Una differenza importante la si può notare in un contesto che prevede l’esecuzione di un’istruzione SQL che non abbia qualificato i nomi di tabelle/viste e che nella stessa istruzione faccia riferimento a tabelle/viste presenti in librerie diverse. P.es. la tabella TAB_A si trova nella libreria LIB_A e la tabella TAB_B nella libreria LIB_B.

select CAMPO_A_1, CAMPO_B_1
  from TAB_A
    inner join TAB_B
      on CAMPO_A_2 = CAMPO_B_2;

Ipotizzando di lavorare con la convenzione di denominazione *SYS inizialmente (a meno di aver modificato le proprietà JDBC di default) la sessione di lavoro SQL eredita la lista libreria dalla descrizione del lavoro del profilo utente con cui ci si collega. Quindi se in questa lista di librerie sono elencate le librerie LIB_A e LIB_B che contengono le tabelle/viste a cui fa riferimento l’istruzione viene eseguita con successo.

Se invece nella lista libreria non sono presenti le librerie LIB_A e LIB_B occorre aggiungerle nella sessione di lavoro SQL. Per riuscire ad eseguire l’istruzione con successo bisogna evitare di modificare la proprietà current schema, ma agire solamente sulla libreria corrente (CHGCURLIB) o sulla lista librerie (ADDLIBLE) utilizzando i comandi del sistema operativo eseguiti tramite la procedura QCMDEXC. P.es.

call qsys2/qcmdexc('CHGCURLIB LIB_A     ', 20);
call qsys2/qcmdexc('ADDLIBLE LIB_B      *FIRST', 27);

-- oppure da 7.1 più semplicemente
call qsys2/qcmdexc('CHGCURLIB LIB_A');
call qsys2/qcmdexc('ADDLIBLE LIB_B *FIRST');

-- oppure si possono aggiungere entrambe nella lista librerie senza modifica la libreria corrente
call qsys2/qcmdexc('ADDLIBLE LIB_B *FIRST');
call qsys2/qcmdexc('ADDLIBLE LIB_A *FIRST');

In questo modo entrambe le tabella TAB_A e TAB_B verranno qualificate correttamente.

Se invece si impostasse o la libreria LIB_A o la LIB_B come current schema e l’altra aggiunta in lista librerie (con ADDLIBLE tramite procedura QCMDEXC), succederebbe che entrambe le tabelle TAB_A e TAB_B verrebbero qualificate con la libreria impostata come current schema ignorando la lista librerie.

SQL path

La proprietà SQL path viene utilizzata per risolvere tutti gli oggetti di database non qualificati che non siano tabelle o viste, quindi p.es. funzioni, procedure…

Bibliografia