select *

from likp as a inner join lips as b

                              on a~vbeln = b~vbeln

                    inner join kna1 as c

                              on b~kunnr = c~kunnr

                    inner join adrc ad d

                              on c~adrnr = d~adrnr

where ....

필들명들은 좀 틀린거 같은데요.. 그래도 위와 같이 하겠다는 뜻 아니신지?

for all entries 가 없어도 될 것 같은데요.

정군님 답변감사합니다.

저도 그렇게 조인 생각했었는데 저 4개의 테이블을 다 조인하면 부하가 많이 걸리거나 그렇진 않나요?

계속 몇번이나 조인을 나눠서 하라는 말을 들어서 왠지 3개이상 조인 하게되면 또 빠꾸먹을것 같은느낌이 들어서..

보통은 정군님처럼 4개 테이블정도는 조인으로 처리를 하나요?

데이터 조회하는데 DB쪽 부하가 많이 걸리는게 걱정이시라면  LIKP와 LIPS를 조인해서 얻은 KUNNR을 인터널테이블에 담아서

FOR ALL ENTRIES로 KNA1을 읽어서 ADRNR을 구하여 인터널 테이블에 담은다음 

FOR ALL ENTRIES로 ADRC 테이블을 읽어온다음

LOOP 구문을 이용해서 LIKP,LIPS 항목들과 매칭해주는게 좋을거 같습니다.

그리고 조인의 경우 3개이상 테이블을 조인하는건 좋지않다라는 소리를 들은적이 있었던거 같네요

테라스님 답변감사합니다!

아, 결국 조인이 안되면 For all entries in 써서 뽑아온 결과를 Loop 돌려서 매칭 시켜주는 수 밖에 없는건가요...

두분에게서 Join과 For all entries in 쓰는 방법을 들었는데

결국은 효율성으로 따지자면 For all entries in 으로 결과 출력후 Loop 돌리는걸까요??

참 그게 애매해서 잘 모르겠네요..

조인의 수가 문제가 되는 건 아닙니다.

조인을 어떻게 잘 거느냐가 문제지요. 조인을 건 테이블들이 적절한 인덱스를 탈 수 있게 하느냐 못하느냐가 관건입니다. 예로 든 쿼리가 실제로 잘 되는지는 제가 자주쓰는 테이블이 아니라서 잘은 모르겠습니다만 lips와 likp는 원래 헤더/아이템이니 별 문제 없을 거고 나머지도 그다지 무리가 가지는 않을 듯 합니다.

다만, kunnr이 중복되는 값이 많을 테니 따로 분리하는 것도 좋은 방법이고, native sql인 경우에는 여러 방법으로 덜 조회되도록 만들기도 합니다. open도 다양한 방법이 있을 듯 하구요.

두분 답변 감사합니다. 생각을 정리하는데 많은 도움이 된것같습니다^^