이 중첩된 루프에 대해 공유할 문서가 없으며,더 이상 프로젝트 팀의 일원이 아닙니다. 그래서 나는 왜 내가 여기서 너무 많은 세부 사항을 말할 수 없는지 이해할 수 있기를 바랍니다.
기본적으로 테스트 데이터 관리 소프트웨어의 소위 사용자 지정 규칙에 대해 동일한 테이블에서 세 가지 다른 종류의 조회를 수행해야했습니다. 이러한 사용자 지정 규칙은 매플릿으로 구현되며 수동 변환만 포함해야 합니다. 라우터,필터,애그리 게이터,활성 자바 변환,표현식,조회 변환 등이 없습니다.
이제 가장 복잡한 두 가지 사용자 지정 규칙에 대해 서로 다른 집계 수준에서 이러한 조회 데이터를 보유하는 여러 보조 테이블을 구현해야했습니다. 소스 파일이 텍스트의 4.5 기가바이트로 구성되어 있기 때문에 파워 센터에서 이러한 테이블을 채우는 것은 너무 쉬운 일이 아니었다(응용 프로그램. 43,000,000 레코드); 조회 테이블에는 서로 다른 조회 조건을 가진 세 가지 집계 수준의 데이터가 포함됩니다. 그리고 저는 지도를 세 개로 나누고 싶지 않았습니다. 그래서 나는 내 자신의”동일한”기반 레코드의 식별을 돌봐야했고,나는 애그리 게이터를 혼자 사용할 수 없었다.
내가 기억하는 한,자바와 같은 전통적인 프로그래밍 언어에서는 소스 데이터를 분석하고 이러한 입력 데이터로부터 각각의 조회 레코드를 생성하기 위해 최대 5 개의 중첩 루프가 필요했을 것입니다. 하나의 경험치로 여러 개의 변수 포트로 서로 다른 수준의 집계를 실행하는 것은 유지하기가 쉽지 않지만,초기 실험에서 이것이 여전히 최선의 선택이라는 것이 밝혀졌습니다.언급 한 바와 같이 매핑을 세 가지로 나눌 수 있었지만 각 매핑은 하나의”일반”경험치와 거의 같은 수준의 복잡성을 가졌으므로 이 매핑에서 세 가지 다른로드 경로를 유지하기위한 노력의 가치가 있다고 생각하지 않았습니다.
나는 파워 센터에서 약간의 경험을 가진 모든 사람들이 자신의 연습에서 사소한 매핑 요구 사항에 대한 비슷한 이야기를 생각해 낼 수 있다고 확신합니다. 우리는 그러한 복잡성을 인식하지 못할 수도 있지만 여전히 존재합니다.
예를 들어,누군가가 파워 센터에서 소수를 생성하는 방법을 묻는 2014 또는 2015 의 스레드를 가져 가십시오. 너무 쉬운 일이 아닙니다. 그러한 솔루션을 구축하는 사람은 알려진 경로 밖에서 생각(및 작업)해야합니다. 의심할 여지 없이 파워센터에서 대단한 성과를 거두었습니다. 그래서 이것은 큰 예가 아닐 수도 있지만 더 복잡한 매핑 논리의 좋은 예가 될 수 있습니다.
또 다른 예로,워크플로의 실행을 특정 순서로 조정하기 위해 모든 시스템을 살펴보십시오. 어쩌면 다음과 같은 몇 가지 추가 조건이 있습니다. 이 모든 것들이 임의로 복잡해질 수 있으며,위에서 언급 한 바와 같이 많은 사람들이 그것을 인식하지 못하더라도 비슷한 복잡한 것을 한 번 이상 구축했다고 확신합니다.