2014-12-03 2 views
1

아래의 쿼리를 생각해 냈지만 80,000 개의 결과를 얻으려면 45 분이 걸렸습니다 ... BILLPRC 테이블은 WHERE 절 앞에 총계가 두 배가되었을 것입니다. 그것을 가속화하기 위해 쿼리를 작성하는 더 좋은 방법이 있는지 궁금합니다. 이것은 매우 애매한 질문 일 수 있으므로 더 많은 정보가 필요하면 더 설명 할 수 있습니다.VBA에서 SQL을 사용하여 DB2 데이터베이스에서 작업하는 일부 사용자 정의 보고서를 만들기 위해 JOIN의 CASE를 사용하여 SQL 쿼리를 가속화합니다.

SELECT b.BLCO# || RIGHT('00000' || b.BLACCT, 5) Acct, b.BLRECT Type, b.BLREC# Record, i.INAME || ' ' ||  i.INAME2 Desc, b.BLPPGM# Promo, SUBSTR(b.BLPEFFD, 4, 2) || SUBSTR(b.BLPEFFD, 6, 2) || SUBSTR(b.BLPEFFD, 2, 2)  Eff, SUBSTR(b.BLPENDD, 4, 2) || SUBSTR(b.BLPENDD, 6, 2) || SUBSTR(b.BLPENDD, 2, 2) Exp, CASE 
    WHEN (p.PPPRC1 = '0') THEN (p.PPPRC2) 
    WHEN (p.PPPRC1 != '0') THEN (p.PPPRC1) END Price, 
    CASE 
    WHEN (p.PPPRC1 = '0') THEN (p.PPCST2) 
    WHEN (p.PPPRC1 != '0') THEN (p.PPCST1) END Allow, i.ILASTC Cost 
FROM QS36F.BILLPRC b 
LEFT JOIN QS36F.PROMO p 
    ON b.BLREC# || b.BLPPGM# = p.PPREC || p.PPPGM# 
LEFT JOIN QS36F.ITEM i 
    ON CASE 
    WHEN (b.BLRECT = 'I') AND (b.BLREC# = i.IMFGR || i.ICOLOR || i.IPATT) THEN 1 
    WHEN (b.BLRECT = 'P') AND (b.BLREC# = i.IPRCCD) THEN 1 
    END = 1 
WHERE (b.BLPPGM# != '') AND (b.BLSTS != 'H') 
ORDER BY (b.BLACCT) 

기록 금액 및 사례를 확인할 수없는 느낌이 있습니다.

+0

인덱싱 된보기를 사용할 수 있습니까? – userDEV

+1

가장 먼저 수행해야 할 작업은 QS36F에서 파일을 이동하고 실제 관계형 테이블을 작성하는 것입니다. System/36 환경은 성능이 우수한 SQL에 적합하지 않습니다 (중간 성능의 경우조차도 아닐 수도 있습니다). 실제 파일 정의를 자세히 살펴보십시오. – user2338816

+0

'b.BLREC# || b.BLPPGM # = p.PPREC || p.PPPGM #'은 멀티 파트 키를 가지고 있음을 의미합니다. 이는 훌륭한 정규화 방법을 위반하는 것입니다. 또한 인덱스를 사용할 수 없으므로 쿼리가 느려질 수 있습니다. 서로 열을 비교할 수 있습니까? 'SELECT CASE'는'p'가'null' 일 때 명시 적으로 대소 문자를 나열하지 않습니다. DB2에는 CYMD 날짜를 다른 형식으로 변환하는 유틸리티가 있습니다. 'ON CASE'는 'OR'조건으로 작동하고 일부는 도움이됩니다. –

답변

2

조인 조건으로 다시 작성하여 WHERE 조건부 (b.BLPPGM# != '') AND (b.BLSTS != 'H')을 변경하면 성능이 향상 될 수 있습니다.

가능한 경우 가입에 사용 된 입력란을 연결하지 마십시오. 예를 들어, 대신

LEFT JOIN QS36F.PROMO p 
    ON b.BLREC# || b.BLPPGM# = p.PPREC || p.PPPGM# 

의 위해 당신은, 물론

LEFT JOIN QS36F.PROMO p 
    ON (b.BLREC#, b.BLPPGM#) = (p.PPREC, p.PPPGM#) 

당신의 WHERE 절에서 논리에 추가이

LEFT JOIN QS36F.PROMO p 
    ON b.BLREC# = p.PPREC 
    and b.BLPPGM# = p.PPPGM# 

또는 동등

LEFT JOIN QS36F.PROMO p 
    ON (b.BLREC#, b.BLPPGM#) = (p.PPREC, p.PPPGM#) 

말할 수 상응하는 폰딩 필드는 같은 유형 또는 호환 가능한 유형이며 이상적으로 필드는 동일한 크기입니다. DB2는 종종 한 유형을 다른 호환 가능 유형으로 자동 변환 할 수 있습니다. 문자열 유형은 종종 서로 호환되며 숫자 유형은 서로 자주 호환됩니다.

그런 다음 가장 중요한 것은 올바른 색인을 사용할 수 있는지 확인하는 것입니다. (나는 S/36 모드 환경에 너무 익숙하지 않지만 인덱스를 만들 수 있다고 가정하고 있습니다.) 인덱스는 파생 된 열, 즉 다시 작성 될 수 있습니다. 연결과 같은 표현.

+0

JOIN의 연결은 옵티 마이저에 선택할 수있는 인덱스가 없으므로 성능이 저하 될 수 있음을 의미합니다. 인덱싱에 대한 조언 (여러 번 주어짐)은 SQL 실행 시간을 줄이는 일반적인 방법입니다. –

+0

파일은 눈에 띄는 외부 설명이므로 IDAD 데이터 사전 (DTADCT)의 파일 정의로 링크되었거나 이전에 설명 된 경우에도 해당 시나리오는 아무런 영향을 미치지 않습니다 (10 진수 데이터가 잘못된 경우 제외). 위치는 라이브러리 이름 [QS36F] 또는 운영 환경 \ mode [S/36EE]로 인덱싱을 제한하지 않습니다. 모드 및 라이브러리와 관계없이 [파생 된] 키순 액세스 경로를 작성할 수 있습니다. 동일한 연결을 포함하는 파생 키 AccPth는 조인을 구현할 자격이 있어야합니다. – CRPence

1

실제로 CPU 시간을 감당할 수없는 경우를 제외하고는보고 목적으로 materialized query table을 사용하십시오. 약간 게으른 것이지만, MQT는 시간별로 업데이트 된 결과를 얻는 것이 좋을 때를위한 것이며 데이터베이스 정규화 및 최적화를 시작하지 않으려는 경우에 적합합니다. 당신은 일하는 논리를 가지고 있으며, 분명히 이해할 수 있습니다. 그것은 내가 용 DB2처럼

+0

어떤 경우에 MQT가 이런 경우에 방수 처리되거나 더 효율적이라고 제안합니까? 참조하는 기사는 DB2 LUW 용이며 DB2 for i에서는 항상 정확하지는 않습니다. 이 질문은 DB2 LUW와는 다소 다른 기능을 가진 IBM i에서 실행되는 DB2에 대한 것입니다. 예를 들어, MQT는'MAINTAINED BY USER'이어야하며 시스템에 의한 자동 새로 고침은 없습니다. – WarrenT

1

이, 당신은 그것이 가정 적절하게

그것을 태그를 할 수 있습니다 .... 보이는 당신은 DB 있는지 확인하기 위해이에 iNav의 실행 SQL 스크립트의 옵션을 "실행이 & 설명"사용했다 새로운 색인을 추천합니까?