nincs olyan dokumentumom, amelyet megoszthatnék ezekről a beágyazott hurkokról, és már nem vagyok része a projektcsapatnak, így csak annyit tudok mondani róla, hogy a fejem tetején van. Remélem, megérted, miért nem tudok túl sok részletet elmondani.
alapvetően három különböző típusú keresést kellett végrehajtanom ugyanazon a táblán egy úgynevezett egyéni szabályhoz a teszt Adatkezelő szoftverben (TDM). Ezek az egyéni szabályok mappletként vannak implementálva, és kizárólag passzív transzformációkat kell tartalmazniuk. Nincsenek útválasztók, szűrők, aggregátorok, aktív Java transzformációk, csak kifejezések, Keresési transzformációk és hasonlók.
most a két legösszetettebb egyéni szabályhoz több kiegészítő táblát kellett megvalósítanom, amelyek ezeket a keresési adatokat különböző aggregációs szinteken tárolják. Ezeknek a táblázatoknak a kitöltése a Powercenterből nem volt túl egyszerű, mert a forrásfájl 4,5 GB szövegből áll (kb. 43 millió rekord); a keresési táblák az összesítés három különböző szintjén tartalmaznak adatokat, különböző keresési feltételekkel. És nem akartam három részre osztani a térképet. Így volt, hogy érdekel azonosítása “azonos” alapú rekord a saját, nem tudtam használni aggregátorok egyedül.
amennyire emlékszem, egy hagyományos programozási nyelvben, mint a Java, legfeljebb öt beágyazott hurokra lett volna szükségem a forrásadatok elemzéséhez és a megfelelő keresési rekordok létrehozásához ezekből a bemeneti adatokból. A különböző szintű aggregáció végrehajtása több változó porttal egyetlen EXP-ben nem túl könnyű fenntartani, de az első kísérleteim során kiderült, hogy ez még mindig a legjobb választás volt; mint említettük, a leképezést háromra oszthattam volna, de mindegyik leképezés majdnem ugyanolyan bonyolultságú lett volna, mint az egyik “általános” EXP, ezért nem gondoltam, hogy érdemes három különböző betöltési utat fenntartani ebben a leképezésben.
biztos vagyok benne, hogy mindenki, aki némi tapasztalattal rendelkezik a Powercenterben, némi gondolkodás után előállhat egy hasonló, nem triviális leképezési követelményekkel a saját gyakorlatából. Lehet, hogy nem is vagyunk tudatában az ilyen összetettségnek, de még mindig ott van.
példaként Vegyünk egy szálat 2014-ből vagy 2015-ből, ahol valaki megkérdezte, hogyan lehet prímszámokat generálni a Powercenterben. Nem túl könnyű. Aki ilyen megoldást épít, annak az ismert ösvényeken kívül kell gondolkodnia (és dolgoznia). Ez kétségtelenül rendkívüli eredmény a Powercenterben. Tehát ez nem lehet nagy példa, de jó példa lehet a bonyolultabb leképezési logikára.
további példaként nézzen meg minden olyan rendszert, amely egy bizonyos sorrendben koordinálja a munkafolyamatok végrehajtását. Talán néhány további feltétellel, például “az XYZ tulajdonsággal rendelkező rekordok száma egyenlő az ABC értékkel”. Ezek a dolgok önkényesen bonyolulttá válhatnak, és – mint már említettük-biztos vagyok benne, hogy sokan építettek már egyszer vagy többször is valami hasonlóan komplexet, még akkor is, ha nem ismerték fel.