Chtěl bych se zeptat, jestli součástí školení bude i několikadenní přednáška o tom, jak se v produktech Oracle nesmí hledat chyby a nedej bože dělal reverzní inženýring kódu. Nazval bych tuto nosnou část školení například: "No, You Really Can't". Součástí by měl být také brainwashing na téma, jak bychom měli slepě důvěřovat svému dodavateli.
To ti vysvětlím za 5 minut a zadarmo:
1. Nesnažit se hledat chybu pomocí logiky
2. Zkoušet náhodně měnit různé kusy kódu a nastavení dokud se to nerozjede
Toto je standardní způsob řešení chyb v oracle
Příklad:
SELECT a.* FROM Account AS a WHERE a.UserName != 'krtek'
Chyba v dotazu: ORA-00933: SQL command not properly ended
Z chybové hlášky je naprosto jasné že mezi "Account" a "a" nesmí být "AS"
V tomhle pripade na tom neni zadna databaze lip. SQL ma hodne divokou gramatiku a bez backtrackingu se proste parsovat neda. A kdyz se parser nekolikrat rozejde dopredu a pak se zase vrati, aby vyzkousel vsechny vetve, tak proste nemuze rict kde presne je chyba (u kazde vetve skoncilo parsovani nekde jinde).
Navic Oracle uz fanaticky dodrzuje zpetnou kompatibilitu. uz minimalne 20 let nepribylo v Oracle zadne rezervovane slovo - tzn. takove ktere nejde pouzit pro nazev tabulky. Pridavaji se pouze klicova slova - tzn. takova, ktera mohou mit zvlastni vyznam, ale zaroven je muzete pouzit pro jmena objektu. Dodnes muzete pojmenovat tabulky jmeny jako A (soucast IS A SET operatoru), AS, JOIN anebo COMMIT.
Cim je gramatika slozitejsi, a Oracle SQL je opravdu hodne slozite, tim hure se hleda kde vlastne presne doslo k chybe parsovani. Navic si myslim, ze nejakej rozumejsi tool Toad/SQLDeveloper/Tora by vam aleson nejaky offset chyby vratil. Pouziva se k tomu dbms_sql.parse.
PS: kdyz vidim jaky zvrhlosti provadi MySQL se svym klonem SQL, tak na tom budou za chvili jeste hur.
PPS: pokud jde o DB2, tak se mi vzdy vybavi tohle: http://www.hovnokod.cz/763