Egy SQL-verseny elvi és gyakorlati problémái

.
Ha valaki rákeres SQL kulcsszóval milyen állásokat hirdetnek ilyen tárgyú site-okon (Profession, Jobmonitor, stb.), akkor bármely, akár "punnyadásos", időpillanatban is egyfelöl jó eséllyel fog találni több nyitott poziciót, másfelöl könnyen valószínűsítheti, hogy "trendi" és ígéretes szakma általános követelménye, aminek következtében, megint csak könnyen valószínűsíthetően, jó sok jelölt pályázhat meg egy-egy állást, ahol SQL-lel kell dolgozni.

Ilyen esetekben munkáltató oldalról felmerül az (1) alkalmasság(előszűrés) illetve a (2) legjobb jelölt (versenyszerű) kiválasztásának triviális igénye. Kérdés van-e - és ha igen, akkor mennyire jó - módszertan ilyen jellegű kérdések megválaszolására? Könnyű-e annyira az SQL-tudás mérése, mint a nyelvtudásé (ahol pár perc diskurzus után megbízhatóan érzékelhető, ki mennyire jó nyelvből -> feltéve persze, hogy a munkaadó bír releváns nyelvtudással, ugye).

Nyelvtudás témájából is blogposzt-hegyeket lehetne írni (itt egy friss aktuális példa: Miért kérnek idegen nyelveket?), de most fókuszáljunk csak az SQL-tudásra és mérésére.

Első nehézség, mik a legfontosabb ismérvei egy jó SQL-esnek. Biztosan vitatható lesz amit mondok, én úgy vélem, hogy az alábbi öt dolog:

(1) Megbízhatóság, hogy egy megírt SQL-parancs tényleg azt csinálja, amit a fejlesztője akart. Komoly, aggregált, nagy futási idejű SQL-lekérdezést nem nagyon lehet sokszor futtatni (adott esetben még egy rossz futást lelőni is probléma lehet), és debugolni sem olyan könnyű, mint egy 3GL kódot.A dolog hatványozottan fontos tud lenni meglévő kódok módosítása esetén. Egy-egy rontáson nagyon sok múlhat, miközben a tesztelési költségek behatároltak, pláne nagyon nagy adatbázisoknál.

(2) Gyorsaság: ki kell tudni használni a deklaratív programozás fejlesztési előnyeit.Pláne figyelembevéve az RDBMS-ek magas alap és támogatási bekerülési költségeit, amik az SQL fejlesztési és végrehajtási előnyeit biztosítják.

(3) Komplex - például inline view-s - sql-ek olvasási, írási és módosítási készsége

(4) Logikai műveletek minél hibamentesebb értelmezése. Magam részéről nem pártolom az összetett logikai kifejezések eröltetését, a hibázási valószínűség robbanásszerű növekedésének lehetősége miatt, de ettől még mások preferálhatják és olvasni kell tudni az ő SQL-jeiket.

(5) Képes legyen kölcsönös kétirányú leképezésre/változtatásra (agyban) a fejlesztő, az SQL és a resultset között. Elismerem ez így nagyon homályos és képlékeny, ha analógiát akarnék keresni, akkor valami olyasmire gondolok, hogy a programozó sem soronként "nulláról" ír programkódot illetve képesnek kell lennie a gép "fejével" gondolkodnia. SQL-nél "kevesebb" karakter kell ugyan a kódoláshoz, viszont a resultset "elképzelése" szerintem nélkülözhetetlen követelmény, a hatékony SQL-parancs megfogalmazásához (sőt mindezt végrehajtási aspektusokkal vegyítve)

Magam részéről - egészen a mai napig - úgy gondoltam, hogy, ha nekem kéne valaki jó SQL-est kiválasztanom több emberből, akkor én például a magyar nyelvű szakmai SQL-levlistáról választanék egy-egy problémát és arról beszélgetnék a jelöltekkel. (Ezt előzetesen jelezném is feléjük.) A kiválasztott probléma lehet elméleti is, gyakorlat is (hibakeresés, sql-módosítás, resultsetes sql elemzés, stb.)


Ily módon, 

(1) legalább valamennyire "zárt" a tudásbázis (még ha zajos is).

(2) de kellően "nyitott" is (hiszen régóta van sokezer hozzászólás, feladat, és így nehéz - végeredményt befolyásolóan - célraorientáltan készülni)

(3) aki a levlistán van (erőforrást fektet olvasásába/írásába), annak legyen ennyi "természetes" előnye

(4) a jelölteket felmérő is "(meg)dolgozik", hiszen közreműködik a kiválasztásban: persze nézőpont kérdése, hogy ez mennyire előny -> az én szememben az.

(5) végeredmény konvergálhat a kiválasztás jóságához, például azzal is, hogy a való életből választódik probléma.


Na, de mi a helyzet, ha

(1) több tíz potenciális jelentkezőre kéne minél megbízhatóbban sorrendet alkotni

(2) papír-ceruza alapon kéne dolgozni

(3) nem klasszikus alkalmassági-/vizsgamegfelelés, hanem versenyszerű alapokon való kiválasztás a cél?

Amióta egyre intenzívebben mozgok adatbányász világban, azóta ternmészetes módon izgatnak a verseny-aspektusok. Na ez most ezennel begyűrűzött az SQL-világba is. :o) Annyira azért nem tartom triviálisnak az SQL-versenyzést,  de jó játék lehet belegondolni, hogyan lenne érdemes ilyesmit lebonyolítani.

Lehetséges felvetések/problémák egy egyáltalán nem futurisztikus SQL-verseny kapcsán:

* Kezdem egy elméleti (definiciós) kérdéskörrel: létezik SQL-re "rátermettség"? Aki jó 3GL-es, abból feltétlen "implikálódik" jó SQL-ezés képessége? Stb.

* Legyen OCA/OCP típusú (angol) feleletválasztós teszt a versenyzés alapja? Ez jó lehet disztingválásra, kiválasztásra? Mennyire él egy angol nyelvvizsga feleletválasztós tesztjével való analógia (állítólag az a mondás és ezért preferálják, hogy a jobb angolos jobban tölti ki őket, az én saját tapasztalatom, hogy az ilyen teszteket jobban töltöm ki, mint amennyire jó angolosnak tartom magamat. Avagy a ceruza-papír alapú és/vagy felelet-választós módi leginkább csak alkalmassági előszűrésre alkalmas, versenyzésre nem igazán?

* A győztes jósága mennyiben korrelál az kiválasztás jóságával (elsőfajú hibázás lehetőségei)?

* Létezik-e (és mennyire) olyan SQL-teszt, amit ha valaki nem kellően jól tölt ki (és bukik), attól még érdemes lenne alkalmazni (másodfajú hibázás lehetőségei)?

* Mennyire legyen "nyitott" az anyag? Lehessen rá készülni valahogy előzetesen? Erről célszerű-e bármit egyeztetni a jelöltekkel?

* Mennyire fontos a (help/internet nélküli)  precíz szintaxis szempontja versenyzésnél? Ha az a feladat, hogy írjon be valaki például natív dinamikus ciklusos select feldolgozást pár sorban, abban "lehet-e" hibát ejteni? Lehet-e, jó sql-es, aki helpből másolgat átírásra kódot?

* Az Oracle pszeudó-, sor- és analitikus függvényei, hierarchikus lekérdezései mennyire erős/ütős szempontok képességmérésben? Egyáltalán mi a helyzet az ANSI szabvány vs. Oracle-specifikumokat illetően?

* Sql-performancia? Hintek?

* Sql vs PlSql? Ha PlSql (3GL) is, akkor ott azért már komoly versenyfeladatok képzelhetők el, kérdés persze, hogy az RDBMS-világtól mennyire elszakadóan.

* Meg lehetne-e tölteni egy könyvet jó versenyfeladatokkal?

Na most itt abbahagyom a további kérdés-kigenerálást. :o)


UPDATE-1.

Némileg revideálnom szükséges álláspontomat, azután, hogy tegnap este, nulla rákészülés után, éles körülmények között kitöltöttem otthon, egy gyári, hivatalos, angol nyelvű 1Z0-047 kódú Oracle SQL Expert tesztet. Egy ilyen teszt során 70 kérdésre kell válaszolni, két óra leforgása alatt. 60%-nyi jó válasz után sikeres a vizsga. Nem síma feleletválasztós volt a teszt (mint nyelvvizsga teszteknél), mert van, hogy több jó megoldás is lehetséges volt egy-egy kérdésnél (viszont meglepő módon előre jelzik a tényt is, sőt, hogy hány jó választ várnak el az adott kérdésnél).A két óra is bőven elegendő volt (sőt szerintem túlméretezett), mégha eléggé meg is terhelő a teszt-kitöltés maga.

Parádés módon nagyszerű (plusz élvezetes) volt az a teszt, amit kitöltöttem. 100%-ban olyan dolgokra kérdezett rá, amit szerintem is tudnia kell egy jó SQL-esnek, egyetlen "aljasság" és/vagy vitatható dolog nem volt a tesztkérdések között (nem úgy, mint nyelvvizsga teszteknél). Rendkívüli módon kiváló "vérfrissítésre" is alkalmas, jó tréningnek tartom ezt a fajta tesztet.

Nagyon tetszett a tesztben az is, hogy rengeteg kérdés volt SQL-olvasásra. Vagyis adtak adatmodellt és/vagy SQL create&insert scripteket, és az ezekre megírt közel nem triviális SQL-eket kellett elemezni a kérdés megválaszolásához (alapvetően ANSI SQL-eseket). Én az ilyen típusú feladatokat tartom a legegészségesebbnek.

A teszt alkalmas lehet a szakmai angol tesztelésére is (esetleg szükség esetén némileg tuningolva, mert a teszt angolja tényleg nagyon egyszerű volt). Továbbá szerintem megoldja azt a problémát is, hogy feltétlen kelljen papír-ceruza alapon kódokat írni (help nélkül).A teszt-kiértékelés is tudhat menni könnyedén.

Szóval nem biztos, hogy fel kell találni a meleg vizet még egy versenyszerű kiválasztáshoz sem. Ilyen tesztekből bárki össze tud állítani magának egy jó tesztet saját használatra,sőt bővítheti feladatbankját saját SQL-olvasási/-módosítási példákkal. Esetleg PlSql-tesztekből is át lehet emelni példákat szükség esetére. Kiváncsi lennék hányan élnek ilyen módival.

Nekem mindig is voltak kifogásaim egy OCP-vizsgával, leginkább olyan téren, hogy szükséges volt hozzájuk valami nem éppen jó, olcsó és/vagy hasznos Oracle eszköz(ök) precíz tudása. Márpedig abból, hogy az Oracle jó és sikeres RDBMS-t tudott fejleszteni, nem következik, hogy jó és sikeres front-end eszközöket is tud(ott). Sőt. Ezt a fajta Oracle-specifikumot (és eröltetését) én perdöntő módon inkorrektnek tartom, ami alkalmas lehet súlyos aránytévesztésre/megtévesztésére is a vizsgára befizetők, valamint a jóhiszemű potenciális munkadók körében. Na ez a mostani Oracle SQL-Expert teszt hálistennek visszaadott némi jó szájízt.


UPDATE-2.

Hali,

Itt egy kilenc feladatos, Papír-ceruzás SQL-teszt. Kidolgozási idő szigorúan egy óra. Emlékezetből írom, nem kizárt, hogy hibázok. Ezért előre is elnézést kérek.

Ügyfél(ügyfél_id,ügyfél_név)
Számla(ügyfél_id,számla_id,egyenleg_dátum,számla_egyenleg)
Tranzakció(tranzakció_id,ügyfél_id,számla_id,tranzakció_ideje,tranzakció_összeg)
Ügyfélkapcsolat(id,ügyfél_id1,ügyfél_id2)

1. Listázandók az inaktív ügyfelek, akik az elmúlt 30 napban nem tranzaktáltak.

2. Az ügyfeleknek hány számlájuk van?

3. Az aktuális számlaegyenlegekből meghatározandó a 30 nappal ezelötti számlaegyenlegek, a tranzakciós adatok révén.

4. Itt volt egy 30 napi forgalmi adat alapján valami kiválasztás. Egyszerű volt, de már nem emlékszem rá vissza pontosan. :o(

5. Akkor nem tekinthető sikeresnek egy napi zárás, ha a tranzakció táblán a napi összesítés nem fut ki nullára. Mely napokon nem volt sikeres zárás?

6. Listázandók azon ügyfelek, akiknél van legalább egy 45 napos intervallum, amikor több mint 100.000 fórint jóváírás érkezett.

7. Egy ügyfél közvetlenül és közvetetten is kapcsolódhat egy másik ügyfélhez (egy másik ügyfélen keresztül). A tranzitivitási lánc tetszőleges hosszú lehet. Egy-egy ügyfélnek hány (közvetlen és közvetett) kapcsolata van?

8. Készítendő egy output, ahol ügyfél_id-nként az első, második, harmadik számlához tartozó pozitív előjelű tranzakció összegek végösszege jelenik meg, 2010.11.01 utáni tranzakciókra.

9. Listázandók azon ügyfelek, akiknek legalább 7 negatív összegű tranzakciója van 2010.11.01-től kezdve, ezen tranzakciók átlaga kell ügyfelenként, úgy, hogy a három legkisebb és legnagyobb összegű tranzakció nem számolódik bele az átlagba.

Azt gondolom ez egy igazi emberkínzós "teszt"(?), mind megírni, mind kijavítani (pláne nagyüzemben). Főleg annak ismeretében, hogy az én kézírásom csúnyább, mint a világ legcsúnyább nője, a néhai Zámbó Jimmy....
;)

Az egy óra is elég kevés érzésem szerint, én legalábbis kihasználtam a rendelkezésre álló időt.

A feladatok viszont zseniálisak, szvsz. Ezért is osztom meg őket, tanulságképpen.


UPDATE-3.

Szerintem a legfontosabb azonosítani, hogy szakmailag mitől jó egy SQL-es, ahogy ezt fentebb is megkíséreltem. A további kérdésekre az én válaszkezdeményeim:

* Szvsz, aki (ösztönösen) jó 3GL-ben, nem feltétlen jó SQL-ben is. De van komoly esélye jónak lennie benne, leginkább avval, ha sikerül érdemben ráéreznie az ízére. Sokkal nehezebbnek érzem az átmenetet 3GL és SQL között, mint két 3GL nyelv között. Valamint én megkülönböztetek OLTP-s és adattárházas (analitikus) SQL-est is. Az elöbbi lényegesebben könnyebb műfaj, szvsz.

* Immáron azt vélem, hogy a feleletválasztós teszt csomó előnyén túl, a versenyszerű kiválasztásra is alkalmas (legalkalmasabb?). Főleg, hogy a kiválasztásnál egyéb szempontok is vannak, más véleményekkel összhangban. Azt nehezen tudom elképzelni, hogy aki jól tud olvasni/módosítani kemény komplex SQL-eket, az ne tudna írni is jól SQL-eket. (Nyelvnél ez például távolról sincs így, szvsz). De befolyásolható vagyok a kérdésben. ;)

* Az elsőfajú hibázást sokkal valószínűbbnek tartom mint a másodfajú hibázást. Analógia: szerelembe könnyebb esni, mint komoly, tartós, boldog házasságba lépni. Illetve, ha valaki első körben ellenszenves, nehéz lesz lesz másodjára szerelemre kiválasztani, még ha jó sok hálivúdi film is szól ilyesmiről. ;)

* Én pártolom, hogy minél zártabb legyen az anyag, amiről szólna a verseny (előzetes informálással), de nyilván nem publikus tesztsor alapján versenyeztetnék.

* Én nem vagyok híve a precíz szintaxis számonkérésének (tőlem még a hierarchikus query vázát is lehet helpből másolni, az analitikus függvényekről nem is beszélve). Például mert hasznosabb agyi tevékenységek elöl veheti el az erőforrást. De el tudom fogadni az ellenvéleményt is.

* Tetszik nem tetszik, az ANSI-szabvány "tudása" nehezen megkerülhető. Olvasni mindenképpen kell tudni ilyen SQL-eket, szvsz.

* Oracle-specifikumok nálam opcionális kategória. Szerintem fontosabbak az eddigi szempontok, illetve ezek a specifikumok menetközben felszedhetők, külön tanfolyam nélkül is. De el tudom képzelni, hogy valaki munkaadó igényelje ezt kiválasztásnál valamilyen (rákérdezési) szinten.

* Nem OLTP-s, hanem analitikus SQL-ezésnél, szerintem érdemes firtatni performancia-kérdéseket, ahogy PlSql-es kérdéseket is, de ez az esetemben lehet, hogy már az agykárosodás kategóriája. :o)

* Hogy mennyire vendorspecifikus kell legyen a kiválasztás? Én inkább úgy teszem fel a kérdést, hogy drágább RDBMS-hez, talán drágább alkalmazottak tartoznak jellemzőbben (hogy mennyire indokoltan az lehet vita tárgya). MySQl 3.2-höz nem feltétlen alkalmaznék Oracle 11g profit (most így extrapolálva). Viszont, ha MySql-s OLTP-s tudás kell, engem nem zavarna, hogy valaki PostgreSQL-ben szerezte a tapasztalatát (vagy fordítva).

* Azt én is jónak tartanám, ha lennének jó, strukturált és karbantartott feladatbankok SQL/PlSql-re. Bennem a kérdés immáron az, hogy mennyire inkább az önképzéshez tartozóan, és mennyire a versenyszerű kiválasztást támogatva.

* Az emberi és egyéb képességek szerintem is nagyon fontosak (szakmain túl és persze perspektivikusan is). És akkor tényleg ott van még a fizetésigény kérdése is. ;)