私はこれらのネストされたループについて共有する文書を持っていないし、私はもはやプロジェクトチームの一員ではないので、私 だから私はここであまりにも多くの詳細を伝えることができない理由を理解してくれることを願っています。
基本的には、テストデータ管理ソフトウェア（TDM）のいわゆるカスタムルールに対して、同じテーブルで3種類のルックアップを実行する必要がありました。 これらのカスタムルールはマップレットとして実装され、パッシブ変換のみが含まれている必要があります。 ルータなし、フィルタなし、アグリゲータなし、アクティブなJava変換なし、式のみ、ルックアップ変換など。
2つの最も複雑なカスタムルールでは、これらの参照データを異なるレベルの集計で保持するいくつかの補助テーブルを実装する必要がありました。 ソースファイルは4.5GBのテキストで構成されているため、PowerCenterからこれらのテーブルを入力するのは簡単ではありませんでした（アプリ。 43万件); 参照テーブルには、異なる参照基準を持つ3つの異なるレベルの集計データが含まれています。 そして、私はマッピングを三つに分割したくありませんでした。 だから私は自分自身で”同じ”ベースのレコードの識別を気にしなければならなかった、私はアグリゲータだけを使用することはできませんでした。
私が思い出す限り、Javaのような伝統的なプログラミング言語では、ソースデータを分析し、これらの入力データからそれぞれのルックアップレコードを作成するために、最大5つのネストされたループが必要でした。 前述のように、マッピングを3つに分割することもできましたが、各マッピングは1つの「一般的な」EXPとほぼ同じレベルの複雑さを持っていたので、このマッピングで3つの異なるロードパスを維持する価値はないと考えていました。
私は、PowerCenterの経験を持つすべての人が、いくつかの考えの後に、彼/彼女自身の練習から自明ではないマッピング要件の同様の話を思いつくことができると確信しています。 私たちはそのような複雑さを認識していないかもしれませんが、それはまだそこにあります。
例として、誰かがPowerCenterで素数を生成する方法を尋ねた2014年または2015年のスレッドを取ります。 あまりにも簡単ではありません。 そのような解決策を構築する人は誰でも、既知の道の外で考える（そして働く）必要があります。 それは間違いなくPowerCenterの驚異的な成果です。 これは大きな例ではないかもしれませんが、より複雑なマッピングロジックの良い例になる可能性があります。
別の例として、ワークフローの実行を特定の順序で調整するシステムを見てください。 おそらく、”プロパティXYZが値ABCに等しいレコードの数”などの追加条件があります。 これらのことはすべて任意に複雑になる可能性があり、上記のように、多くの人がそれを認識していなくても、同様に複雑なものを何度も何度も構築していると確信しています。