jeg har ikke noe dokument å dele om disse nestede løkkene, og jeg er ikke en del av prosjektgruppen lenger, så alt jeg kan fortelle om det er av toppen av hodet mitt. Så jeg håper du forstår hvorfor jeg ikke kan fortelle for mange detaljer her.
I Utgangspunktet måtte jeg utføre tre forskjellige typer oppslag på samme bord for en såkalt Tilpasset Regel I Test Data Management software (TDM). Disse Egendefinerte Reglene implementeres som mapplets, og de må bare inneholde passive transformasjoner. Ingen rutere, ingen filtre, ingen aggregatorer, ingen aktive Java-transformasjoner, bare Uttrykk, Oppslagstransformasjoner og lignende.
Nå for de to mest komplekse Tilpassede Reglene måtte jeg implementere flere hjelpetabeller som holdt disse oppslagsdataene på forskjellige nivåer av aggregering. Fylling av disse tabellene Fra PowerCenter var ikke så lett fordi kildefilen består av 4,5 GB tekst (app. 43 millioner poster); oppslagstabellene inneholder data på tre ulike nivåer av aggregering med ulike oppslagskriterier. Og jeg ville ikke dele opp kartleggingen i tre. Så jeg måtte ta vare på identifikasjon av «samme» basert rekord alene, jeg kunne ikke bruke Aggregatorer alene.
så vidt jeg husker, i et tradisjonelt programmeringsspråk som Java, ville jeg ha behov for opptil fem nestede løkker for å analysere kildedataene og opprette de respektive oppslagspostene fra disse inngangsdataene. Å utføre ulike nivåer av aggregering med flere variable porter i en ENKELT EXP er ikke så lett å vedlikeholde, men mine første forsøk har avslørt at dette fortsatt var det beste valget; som nevnt kunne jeg ha delt opp kartleggingen i tre, men hver kartlegging ville ha hatt nesten samme nivå av kompleksitet som den ene «generelle» EXP, så jeg anså det ikke verdt innsatsen for å opprettholde tre forskjellige lastbaner i denne kartleggingen.
jeg er sikker på at alle Med litt erfaring I PowerCenter kan – etter litt tanke – komme opp med en lignende historie om ikke-trivielle kartleggingskrav fra egen praksis. Vi kan ikke engang være klar over slik kompleksitet, men det er fortsatt der.
ta for eksempel en tråd fra 2014 eller 2015 der noen spurte hvordan man genererer primtall i PowerCenter. Ikke så lett. Den som bygger en slik løsning, må tenke (og jobbe) utenfor de kjente stiene. Det er uten tvil en ekstraordinær prestasjon I PowerCenter. Så dette er kanskje ikke et stort eksempel, men det kan være et godt eksempel på mer kompleks kartleggingslogikk.
Som et annet eksempel, se på et hvilket som helst system for å koordinere utførelsen av arbeidsflyter i en bestemt rekkefølge. Kanskje med noen ekstra forhold, for eksempel «antall poster med eiendom XYZ er lik VERDI ABC». Alle disse tingene kan bli vilkårlig komplekse, og – som nevnt ovenfor-er jeg sikker på at mange mennesker har bygget noe lignende komplekst en eller flere ganger, selv om de ikke kjente det igjen.