easy abap 31. read 구문/ 인터널 테이블 읽기

- 인터널 테이블에서 원하는 데이터를 읽으려면 READ 구문을 사용한다.

- 만약 헤더라인이 있으면 해당 데이터가 헤더라인으로 복사되고, 그렇지 않으면 Work Area에 복사해야한다.

 

1. Table Key 이용

READ TABLE itab FROM wa INTO result.
READ TABLE itab WITH TABLE KEY k1 = f1.
kn = fn INTO result.

- Key 값을 이용해 값을 찾을 수 있다. 

- result는 read 결과를 저장하게 되는 Work Area이다.

- 헤더라인이 존재하는 인터널 테이블은 into이하를 생략하고, 인터널 테이블 이름 자체를 Work Area로 사용해도 된다.

- 성공하면 Sy-subrc 변수에 0을 반환하고, 실패하면 4을 반환한다

DATA: BEGIN OF gs_line,
	carrid TYPE scarr-carrid,
    carrname TYPE scarr-carrname,
    END OF gs_line.
    
DATA gt_itab LIKE TABLE OF gs_line WITH NON-UNIQUE KEY carrid.

SELECT carrid carrname INTO CORRESPONDING FIELDS OF gt_itab FROM scarr.

gs_line-carrid = 'AA'.
READ TABLE gt_itab FROM gs_line INTO gs_line.
WRITE: / gs_line-carrid, gs_line-carrname.

CLEAR : gs_line.
READ TABLE gt_itab WITH TABLE KEY carrid = 'AB' INTO gs_line.
WRITE : / gs_line-carrid, gs_line-carrname.

AA AMERICAN Airlines
AB Air Berlin

 

- 여기서 왜 `READ TABLE gt_itab FROM gs_line INTO gs_line`이 되는 걸까?

- 같은 gs_line이라 헷갈렸다.

 

FROM gs_line – “찾을 조건”

- 비교대상

• gs_line 안에 들어 있는 값을 보고,
• gt_itab에서 이 값과 같은 행이 있는지 찾음
• gs_line-col1 = 'A' 이 상태에서 gt_itab 내부에 Col1 ='A'인 행을 찾는다.

 

INTO gs_line – “저장할 대상”

 - 결과를 저장할 구조체

• 찾은 row가 있다면,
• 그 전체 행을 gs_line에 덮어씀 (즉, 복사해서 넣는다.)

| gt_itab (내부 테이블)        |
|––––|––––|
| ‘A’    | 10     |
| ‘B’    | 20     |

 

그럼 둘 다 gs_line을 써도 되는 이유는 뭘까? 

- 읽기용(FROM)과 쓰기용(INTO) 역할이 다르기 때문!

- From은 비교용, into는 결과저장용이다.

GPT공부법 시작.

 

 

- DATA gt_itab LIKE TABLE OF gs_line 으로 했을 땐 에러가 나지만, WITH ~ KEY 옵션을 주면 에러가 뜨지 않았다.

- gt_itab이 carrid 기준으로 정렬된 테이블은 아니지만, 내부적으로는 carrid를 검색 기준 필드로 간주할 수 있게한다.

- WITH TABLE KEY는 sorted, hashed에 주로 쓰이지만,

- STANDARD TABLE도 with non-unique key를 지정하면 명시적으로 키를 정의한 셈이 되어 사용할 수 있음

- 속도는 느릴 수 있고, 중복값 처리 주의해야함

2. Work Area할당

 

1. Read 구문의 comparing 옵션

- comparing 구문은 read구문의 결과값에 비교조건을 추가한다.

- 즉, comparing 구문 다음에 기술된 Field들이 work area값과  인터널 테이블에 존재하는 값이 같으면 sy-subrc = 0 을 반환하고, 같지 않으면 sy-suvbrc = 2를 반환한다.

- COMPARING 을 하면 값을 비교할 수 있다.

첫번째 write문은 2가 나오는데, 비교할 gs_line-col2가 없기 때문이고,

그 다음 comparing에서는 gs_line-col2값이 있기 때문에, 0이 나온다. 

 

2. read 구문의 TRANSPORTING 옵션

- Transporting은 read한 결과를 해당 칼럼만 Target에 저장하는 기능을 수행한다.

Transporting의 이유

- 전체 필드가 필요하지 않을 때 : 성능 최적화 기능(불필요한 데이터 복사X)

- 특정 필드 하나만 비교하거나 출력할 때(필드 일부만 가져오기에 나머지는 비어있다!)

- 이 예제를 보고 의문이 든점:

gs_wa는 work area인데, 생각해보니 gs_line은 어떻게 work-area기능을 하는 걸까?

- DATA : ~ END OF gs_line 이라는 이름의 로컬 구조체 변수가 만들어짐 = 이 것도 구조체(work area)다.

- `READ TABLE gt_itab WITH TABLE KEY coll = 'A' INTO gs_wa.` 로 인해, gs_wa에 해당 행의 모든 값이 복사된다.

- `READ TABLE gt_itab WITH TABLE KEY coll = 'A' INTO gs_wa TRANSPORTING col2.` : gs_wa-col2만 복사된다.

Col1 is : Col2 is : First

-> 성능 최적화에는 좋지만, 복사 대상을 주의해야한다.

 

3. Index를 이용해 read구문 수행

READ TABLE itab INDEX idx INTO result.

-index를 이용하여 해당 라인의 값을 읽을 수 있음

- 성공 시, sy-subrc 변수에 0을 반환하고 실패 시에는 4를 반환한다.

 

- A를 세번째에 넣어지만, SORTED라 정렬된 상태라서 Index1번에 들어갔고, index1을 출력하니 잘 나오는 모습을 볼 수 있다!

 

4. READ BINARY SEARCH

- Standard type의 인터널 테이블을 read할 떄 binary search를 이용할 수 있다.

- binary search 대상 칼럼을 기준으로 정렬한 후 사용하며, Read 속도가 일반 속도보다 훨씬 빠르다.

READ TABLE itab WITH KEY k1 = f1 ... kn = fn INTO result BINARY SEARCH.

 

- binary를 하면 실행시간이 굉장히 빨라지며, application server에서 접근하기 때문에 데이터베이스에서 데이터를 가져오는 전자보다 효율적이다.