Advanced PL/SQL előadás

Ma megtartottam életem első prezentációját a munkahelyemen. A cél az volt, hogy át tudjak adni egy szeletet abból, amit a múlt hónapban tanultam az Oracle Database 12c: Advanced PL/SQL tanfolyamon. A feladat nem volt könnyű. Sosem tartottam még előadást, nem volt benne tapasztalatom, ráadásul olyan témákról kellett beszélnem, ami még számomra sem mélyen elsajátított tudásból jön. Nagyon izgultam, kiszáradt a szám, remegett a kezem, de elvégeztem a feladatom :)

"Lesz ez még jobb is" gondolattal zártam magamban, amikor végeztem. Az előadást feltöltöttem, szabadon megtekinthető, talán mások számára is hasznos vagy gondolatébresztő lehet benne 1-2 dolog. Fogok még vállalni előadást, csak ki kell választanom a témát. Legközelebb egy kiragadott problémával szeretnék kicsit részletesebben, hosszabban és mélyebben foglalkozni. A lehetséges témák még kidolgozás alatt vannak.

Alapvetően a 2. slide-on található ábra legalsó szintjéről beszéltem. Szerettem volna az előadással azt is bebizonyítani, hogy a PL/SQL hatékony, rugalmas és teljesítményorientált nyelv. Számos lehetőség van tuningra, hangolásra, optimalizálásra. Aki azt hiszi, jól ismeri a nyelvet, könnyen megesik, hogy nagyot téved. Sok feladatra a legjobb megoldás.

Miért érdemes használni a PL/SQL-t?

Mert hatékonyan tudunk vele SQL-eket futtatni, minden SQL típust támogat. Gyorsabb, mint egy felsőbb rétegből indítani számos SQL hívást, az eredmény feldolgozásban is verhetetlen. Támogatja a statikus és dinamikus SQL-ek írását, kurzor használatát, tranzakció vezérlést. Támogat objektum-orientált programozást. A kód hordozható, újra felhasználható. 

Use FORALL and get pls-00436 restriction

Először is, ez a megszorítás oracle 10g alatt él, 11g és felette már nincs gond. 

Ha 10g alatt akar valaki rekord alapú collekciót használni, nem fog menni.

Nem hiba, hanem feature. 

SQL> DECLARE
  2     TYPE rec_emp IS RECORD (sal emp.sal%type, empno emp.empno%type);
  3     TYPE emp_aat IS TABLE OF rec_emp
  4        INDEX BY PLS_INTEGER;
  5     aa_emps emp_aat;
  6
  7  BEGIN
  8
  9     FORALL i IN aa_emps.FIRST .. aa_emps.LAST
 10        UPDATE emp
 11        SET    sal = aa_emps(i).sal * 1.1
 12        WHERE  empno = aa_emps(i).empno;
 13
 14  END;
 15  /

Errors: check compiler log
PLS-00436: implementation restriction: cannot reference fields of BULK In-BIND table of records

Workaround

Megoldás: mivel nekem csak két mezőből állt a rekordom, így egyszerű volt külön kollekcióként felvenni őket. Több mező esetén már más megoldás kell. Pl.: db upgrade :) vagy át kell írni FOR .. LOOP megoldásra.

SQL> DECLARE
  2     TYPE t_sal IS TABLE OF emp.sal%type;
  3        INDEX BY PLS_INTEGER;
  4     TYPE t_empno IS TABLE OF emp.empno%type
  5        INDEX BY PLS_INTEGER; 
  6   
  7     lv_sal t_sal;
  8     lv_empno t_empno;
  9
 10  BEGIN
 11
 12     FORALL i IN lv_sal.FIRST .. lv_sal.LAST
 13        UPDATE emp
 14        SET    sal = lv_sal(i) * 1.1
 15        WHERE  empno = lv_empno(i);
 16
 17  END;
 18  /

Használj PL/SQL-t!

Általános "bölcsesség" (úgy ötven éve), hogy egy nagyobb szoftver implementálása nagyban függ a megfelelő moduláris tervezéstől. Ma már az adatbázis szint abból áll, hogy lefut egy SQL utasítás (insert, update..) és kész. Holott, ez csupán csak egy része annak, amit alkalmazás funkcionális leírásában specifikáltak mint üzleti tranzakció. Minden funkciót egy API-nak kell megvalósítania, akár számos, különböző (specifikált) módon. 

A következtetés tehát: ezeket a modulokat PL/SQL-ben kell megírni. Teljesen felesleges magasabb szintre vinni az adatbázis táblák neveit, struktúráját. Az adatbázist érintő üzleti funkciókat jól specifikálva, az adatbázis szintjén kell megvalósítani. Biztonságban el kell rejteni az SQL-t az adatbázis szintjén ami ezeken dolgozik.

Ügyfelek egy csoportja általában elégedett a kapott alkalmazás teljesítményével. Van azonban egy másik csoport

• akik rendszeresen panaszkodnak a teljesítményre, mert egy üzleti folyamat gyakran felesleges kerülő utakkal lettek implementálva a középső szintektől az adatbázis szintig 
• aztán panaszkodnak minden kisebb javítás után is, mert az egyszerre érinti az alkalmazás több szintjét is, lényegesen nehezítve a szoftver karbantarthatóságát
• aztán panaszkodnak a javítások számára, mert az alkalmazás tesztelhetősége is bonyolultabb és nehézkesebbé válik, ha több szinten van implementálva egy funkció 

Végül pedig, még egy érv a modularitás megőrzése mellett. Minden szoftver idejében eljöhet az idő, amikor teljesen vagy csak egy-egy funkciót kell átírni, újra gondolni. Ebben az esetben is teljesen egyértelmű, hogy mekkora előnyökkel jár, ha az adatbázis API-k jól meg vannak írva, nem keverve más szintű folyamatokkal.

ERB - Edition-based redefinition

Egy fontos újítás a 12c verzióban. Jelenleg, ha egy PL/SQl-t módosítani kell, le kell állítani az alkalmazást. De a 12c után többé nem. Amikor egy PL/SQL-t, nézetet vagy szinonimát módosítani kell, a módosítás egy új "kiadáson" (edition) fog lefutni, ami az alkalmazás számára láthatatlan. Az alkalmazás megszakítás nélkül fut végig. Amikor minden változtatás megtörtént az új verzión, és ellenőrizve lett, az alkalmazás adatbázis munkamenetei egyszerűen átállnak az új verzióra sorban, amíg már egy munkamenet sem lesz a régin. Majd ez lesz a végleges verzió.