Magamról

Saját fotó
Főiskolai, majd egyetemi diplomamunkáimtól kezdve világ életemben, adatok, adatbázisok, adattárházak (leginkább Oracle) környékén mozogtam. Mostanság adattárházasként, adatbányászként élem napjaimat.

2013. június 16., vasárnap

Miért útálom oly nagyon a TOAD-ot?

v2.0 2013-06-21

2012 Szeptember 28-án a DELL megvette szőrüstől-bőrüstől a Quest céget, ami (mint a SAS is) független gyártóként kétszámjegyű éves múltra tekint vissza. Az ember azt hinné, hogy a független gyártókat jobban szereti az ember a mammutoknál,  vagy szakmaibban szólva megavendoroknál,  (amilyen az Oracle is), de nem: én a Questet is, a SAS-t is útálom, mind a céget magát is, mind a termékvonalatukat és árképzésüket is.

Árlistája szerint a TOAD for Oracle egyes kiadásai 1.000-8.700 euró (300.000-2.600.000 forint) közé esnek licencenként. Most az útálatomtól függetlenül is, 2008-as válság után nem tűnik életszerűnek az ilyetén árképzéses üzleti modell, logikusan várható volt ez a Dell-es akvizició. Ellenpontként a PlSql Developer jelenleg 216 USD, ~40.000 forint.

Öröktől fogva, amióta a világ világ, vagy legalábbis napvilágra került a két termék (Quest TOAD for Oracle és PlSql Developer) felhasználói kvázi kibékíthetetlen ellentétben állnak egymással. Mindegyik az általa használt termékre esküszik. Egyébként én is. ;)
Olyan a szembenállás, mint a Windows kontra Linux. Vagy még annál is durvább. Merthogy én Windows-ban dolgozóként abszolút értelmes és életképes alternatívaként élem meg a Linuxot, de a TOAD-ra például már fújok.  ;)

Ráadásul ami külön szép, hogy abban a Delphiben írták mindkettőt, ami számomra annó a legkedvesebb fejlesztőkörnyezetem volt, és mára széles körben teljesen lenézetté vált, egyébként teljesen jogosan, köszönhetően a Borland "okostojásainak", akik évek szívós és felhasználóellenes munkájával tönkretették a terméket (el is kellett adniuk, hogy ne termeljen további veszteséget, és azóta már ki tudja hanyadik tulajdonosnál vegetál az egyébként jobb sorsra érdemes cucc)

Legyünk rendesek kezdjük a TOAD előnyeivel. ;)

(1) Séma-exportja ritka flexibilis, ez mondjuk tud nehézkes is lenni, ha valaki gyorsan akarna egyet exportálni, annyi - olykor nem is trivális - dialógusablakon kell keresztül verekednie magát az embernek. De az biztos, hogy ennél többet még én sem nagyon tudnék beleképzelni a funkcióba. Persze csak alapértelmezésben... ;)

(2) SQL/DB-tuningolásra abszolút és verhetetlenül ideális. Saját szememmel láttam, hogy egy kollégám milyen hatékonyan támogatta meg egy 8 órába mindenképpen beleférő (SLA) 1400 job-os adattárháztöltést.

(3) DBA-Admin feladatokat remekül támogat. Egy Oracle Enterprise Manager úgy marad el felületében, használhatóságában, teljeskörűségében, hogy árban talán összemérhetőek egymással.

(4) SQL-monitorja egyenesen szenzációs. Gyönyörűen és használhatóan tudtam nézni, hogy a Business Objects Data Services (világ egyik legnagyobb ipari hulladéka, egyébként ETL-eszköz), milyen SQL-ekkel támadja meg az Oracle adatbázist. Segített felderíteni a "természetesen" nem dokumentált repositoryjának kulcsfontosságú részleteit, amiből aztán értékes üzleti funkcinalitást lehetett elérni.

(5) Table-rebuild. Megkreálódik a script, átnevezéssel, constraint-es ki-bekapcsolásokkal, particionálással, indexeléssel, jogosultságokkal, stc. De egyébként is pikk-pakk könnyű a legkülönfélébb reverse engine-s scriptekhez hozzájutni.

(7) Nagyon tetszik a gombra varrt Sql*Plus hívás lehetősége

(6) Session-browser. Fájó elismerni, de sokkal jobb, mint a PlSql Developeré. De tetszik az is, ahogy egyáltalán elválik a Session-, Schema-, Database-browser.

(8) Scheduler-funkcionalitás kidolgozottabb, mint a PlSql Developeré.


Na és akkor miért útálom a TOAD-ot:

(1) A béka-hang. Az első, amit az options-ben kikapcsolok, ha TOAD-oznom kell. ;)

(2) A világ legocsmányabbul formázott SQL-kódját adja ki magából alapértelmezésben, az én értelmezésem szerint.Ha kapok mailben egy SQL-t, rögtön tudom, hogy ha TOAD-dal lett összerakva - a hányingeremből;)

Ebben a témában én egyébként is "perben-haragban" vagyok a világgal.

Valamelyik "vicces" kedvű IT-s figura annó kitalálta (a világ meg bamba módon átvette), hogy az SQL-eket középre kell zárni, mert milyen "jópofa" középen a függöleges space-oszlop. Én meg ha ilyet meglátok, sírhatnékom támad, annyira szörnyűnek, visszataszítónak, problémákat gernerálónak találom.

A másik ilyen hülyeség, hogy az oszlopokat (másodiktól kezdve) vesszővel kell kezdeni a select-listában (illetve and/or-ral az elemi feltételeket a where-clause-ban). Mondván, hogy a vesszőt hajlamos a fejlesztő lehagyni a végéről így könnyebb a fejlesztőnek bővíteni a select-listát. Igen ám, de ez a fejlesztőnek pillanatnyi időre érdekes csak, szemben az SQL teljes életciklusával, mert az SQL-eket majd olvasók igényeivel. A szem fókuszt a vessző prioritása fogja vezérelni, nem pedig a mögötte lévő lényeg. A vessző vagy az AND az csak overhead az SQL-ben kis túlzással, legjobb lenne, ha nem is látszódna, mert hiszen nincs neki semmiféle üzleti tartalma.

Én ezzel szemben azt mondom hogy
- balra kell zárni,
- törekedni kell a minél kevesebb sorra, soronbelüli karakterszámra,
- az inline view-s struktúráknak első pillantásra jól kell látszódniuk,
- normális épelméjű legyen a zárójelezés az olvasó/visszafejtő számára,
- az SQL-formázásnak az átláthatóságot, a biztonságos módosítást kellene támogatnia, nem ilyen vizuális hülyeségeket mint a függőleges space-oszlopot.
Az ész megáll. ....

Nem értelemes fegyelmezett formázással lehetetlen biztonságosan és kultúráltan komplexebb, többszörösen beágyazott SQL-eket írni, amilyet nekem is kellett írni nem is olyan régen (132 KB, 3050 soros SQL)

(3) PlSql Developeresként  számomra rendkívül taszító volt a TOAD-ban mindig is, hogy egy lekérdezés COUNT(*) /rekordszám/-infójáért külön kell klikkelgetnem, amit én mindig azonnal kézhez kaptam azonnal.

(4) A TOAD számomra feleslegesen nagy monstrum (már az indulásánál is látszik, és utána is csak a szívás van vele), mindent összehányva tartalmaz, ami funkciókból - Pareto szabály szerint - 80%-ban használom a 20%-át, amivel szemben mindent ki is kell fizetnem, olvasatomban erősen túlárazott kalkulálás alapján (érdekes módon mint a SAS-nál is).
A PlSql Developer csak a 20%-ot tudja, de azt könnyedén, lightosan, barátságosan, és töredékáron.

(5) Ki merem jelenteni, hogy a TOAD nem fejlesztő eszköz. Csak van neki fejlesztői modulja is. Olyan is az egyébként. ;) TOAD-hívők is mindig csodálkoznak a PlSql Developer elegáns debuggerén, ami valóban támogatja a tárolt eljárások, hogy ne mondjam VIEW-k fejlesztését. (Nem mintha ő sem tudna befagyni, de ez más tészta)

(6) A TOAD-nak lehetne egy nagyszerű, világon egyedülálló feature-e, a lockolásos, csoportos szoftverfejlesztés, verziókontrollal. Ez lenne ugye a Team Coding. Ha nem lenne olyan használhatatlanul lassú és/vagy bug-os, hogy 2 percig(!) tartson (egyébként i5 procis, 8GB RAM-os desktopon) egy checkout-checkin session, olyan hibákkal, hogy a VIEW-k ablakai konkréten semmilyen módon nem bezárthatók utána (TOAD-reboot szükségessége). Az látszik, hogy küszködnek a témával a fejlesztők is,mert az UPDATE-k nagyrészt szólnak Team Coding BugFix-ekről.

Egyrészt én ezt a Team Codingot így használhatatlannak tartom a (jelenlegi formájában), ráadásul semmi mással nem is együttműködésképes csak a Quest termékek szintjén

Másrészt a funkciónak ezt a formáját sem tartom létkérdésnek. Azt gondolom biztonságosan lehet még Subversion-nel vagy SVCO-val is megoldani a problémát/funkciót, ha már az Oracle van olyan "szíves" és 40+ év után sem képes ilyesmit érdemben támogatni RDBMS-ében. ;) Persze jobban szeretem a Microsoft Visual SourceSafe lockolásos módszertanát.

A "2 perc" némi magyarázatra szorul. Életemben sok év után újra egy újabb projekt keretében ismét kellett használnom a General Eletric(=GE) VPN-hálózatát. Sok VPN-t láttam már, dolgoztam bennük, mindközül toronymagasan a legsz*rabb a GE-é.

Régen olyan lassú volt, hogy távolról mailben való karakter-leütés megoldhatatlan problémát jelentett neki (timeout).

A mostani friss élményem, hogy 2013-ban is továbbra is csak az ActiveX-s Internet Explorer-t támogatják. De olyan szinten, hogy a látszatra böngészőfüggetlen Juniper NetWork Connect mélyében is ez a szutyok IE van. Na de hogyan? Az IE 10-es verziót ismeretlen böngészőként ismerik fel (nemdeterminisztikus módon egyébként, van akinek sikerült ezt elkerülnie, de nem tudja, hogyan, miért), ami azonnal "restricted"-használatot von maga után. És persze a Microsoft megteszi azt a "szívességet", hogy a Windows8-ba beégeti az IE10-et, onnan kivakarhatatlan módon. Magyarán mind a Microsoft, mind a GE "jelszava" olvasatomban az, hogy a Windows8-as felhasználók rohadjanak meg, miközben az IE a kötelező standard.

Képezheti-e csoda tárgyát, hogy a TOAD Team Codingja ebben a GE-VPN-ben nem képes felülmúlni saját magát? ;)

Nincsenek megjegyzések:

Megjegyzés küldése