Nu er det efterhånden mange år siden, at det blev muligt at lave OUTER JOINS i DB2, men det er mit indtryk, at mulighederne anvendes forbløffende lidt. For de af jer, der bruger OUTER JOINS, håber jeg, at denne uges tip vil kaste yderlige lys over virkemåden og måske hjælpe lidt på performance, hvor muligheden er der. Ideen i tippet så jeg første gang beskrevet i en artikel af Susan Lawson, en af de førende DB2 guru'er.

Lad mig starte med det sædvanlige eksempel:

SELECT TS.DBNAME, TS.NAME AS TSNAME, TS.NTABLES
     , VALUE(TB.CREATOR, '*') AS CREATOR
     , VALUE(TB.NAME, 'INGEN TABELLER') AS TBNAME
FROM SYSIBM.SYSTABLESPACE TS
LEFT OUTER JOIN SYSIBM.SYSTABLES TB
  ON  TS.DBNAME = TB.DBNAME
  AND TS.NAME = TB.TSNAME
  AND TS.NTABLES > 0
WHERE TS.DBNAME LIKE 'DSN%'

Dette SQL-kald burde være lige til at klippe ud og køre på enhver DB2 mainframe installation. Men hvad er det så lige, at det laver og hvad er pointen? SQL-kaldet finder alle de tabeller i alle de tablespaces, der ligger i de databaser, der starter med DSN. Hvis tablespacet ikke indeholder nogen tabeller (det kan nemt lade sig gøre), så udfyldes kolonnen CREATOR med en '*' og kolonnen TBNAME med teksten INGEN TABELLER. Med en traditionel join var tablespaces uden tabeller slet ikke kommet med i resultatet, men det er jo netop tricket med en OUTER JOIN.

Pointen ligger i selve join kriteriet, der er udvidet med AND TS.NTABLES > 0. Det ligner jo ikke just et normalt join kriterie, hvor man matcher kolonner fra to forskellige tabeller. Faktisk evaluerer DB2 også dette kriterie. Hvis det ikke er opfyldt, så kan de to tabeller ikke joines, og DB2 returnerer kun rækken fra den "venstre" tabel (SYSIBM.SYSTABLESPACES). Det smarte er, at DB2 slet ikke slår op i den "højre" tabel, hvis NTABLES er 0. SQL-kaldet ville returne præcis det samme resultat uden dette ekstra kriterie, men det ville have slået op i SYSTABLES også for de rækker, hvor NTABLES er 0.

Nu er det så bare om at finde andre SQL-kald på din installation, hvor der benyttes OUTER JOINS, og hvor der findes kolonner i den ene tabel, som fortæller om der findes data i den anden tabel eller ej. Disse OUTER JOIN's kan optimeres efter ovenstående princip. Man kan også introducere sådanne kolonner, hvis de ikke findes i forvejen. Det kræver selvfølgelig programændringer, men det kan sandsynligvis betale sig i kritiske applikationer.