콘디의 SAP 개발기

1. ABAP DICTIONARY

- ABAP 프로그램에서 사용되는 오브젝트들(table, view, structure, types..)을 abap dictionary라고 부름

- 이런 오브젝트 정보를 metadata or data definition이라 정의하며, 데이터 구조를 정의하고 관리하는 역할을 ABAP Dictionary가 하게됨

- ABAP dictionary는 시스템에 사용되는 모든 오브젝트들은 중앙 집중식으로 관리됨

- 신규 또는 변경된 Metadata의 정보는 모든 시스템 오브젝트에게 알려진다.

- 다시 말해, ABAP Dictionary는 동적으로 ABAP WORKBRENCH와 연결되어 있기 때문에 오브젝트를 변경하면 아밥 프로그램과 스크린에 바로 영향을 미친다.

- 시스템에서 사용되는 모든 데이터들을 중앙집중적으로 관리한다

- 무결성, 일관성, 안정성을 보장한다.

* Database Object - Table,View

* Type Definition - Structure, Data Element, Table Type

* Tool - Search Help, Lock Object

2. ABAP DICTIONARY 종류

1) database object

- table은 시스템에서 생성된 데이터를 저장하는 실제 물리적 공간으로 데이터베이스의 바탕을 이룸

- view는 하나 이상의 Table이 논리적으로 결합한 구조로서, 실제 데이터를 가지는 것이 아닌 table의 데이터를 조합해 조건에 맞게 조회하는 기능을 주로 함

2) Type Definition

- abap dictionary는 사용자 정의 type(data elements, structures, table types)을 지원함

- 개별 프로그램에서 사용되는 type은 types구문으로 생성하지만 모든 abap프로그램에서 사용할 수 있는 type object는 abap dictionary에서 정의함

- 중앙 집중식이기에 type object를 변경하면 모든 프로그램에 영향을 미치게 함.

* Data element : 필드의 내역과 같은 어의적인 정보를 가짐

- domain은 테이블 필드의 기술적 속성을 정의하는 오브젝트

- abap프로그램에서 참고하여 변수를 선언할 수 없다.

* Structure : Structure은 타입을 가지는 Component로 구성되어있다.

* Table Type : 인터널 테이블의 기능적 속성을 정의하는 데 사용함.

- 특별 형태인 Range Table Type이 존재한다.

* ABAP TOOL

- avap dictionary tool은 데이터를 관리하고 정의하는 기능 이외에 프로그램에서 추가로 필요한 기능을 통칳함

f4를 입력하면 possible entry로 조회되는 search help를 의미함 

어김없는 GPT TIME~~

[문제 1] OX 퀴즈 채점

1. X 

- READ TABLE ... 은 기본적으로 **순차 검색_Standard Table**을 합니다.

- 키 검색이 되려면 with key or with table key 지정 

2. O

- TRANSPORTING 은 성능 향상을 위해 특정 필드만 읽거나 수정할 때 사용

3. X 

- MODIFY ... FROM wa. 는 기본적으로 Standard TABLE에서는 여러 행을 변경할 수 있어서 한 행만은 아님

4. O

- LIKE LINE OF는 내부 테이블의 한 줄과 동일한 구조의 워크영역을 만드는 데 사용함

5. X

- DELETE ADJACENT DUPLICATES는 정렬이 되어 있어야 인접 중복을 삭제할 수 있음 SORT BY를 먼저 해줘야 함

[문제 2] 코드 실습 채점

DATA : BEGIN OF t_flight,
	carrid TYPE sflight-carrid,
    fldate TYPE sflight-fldate,
    END OF t_flight.

DATA : BEGIN OF t_scarr,
	carrid TYPE scarr-carrid,
    carrname TYPE scarr-carrname,
    END OF t_scarr.
    
DATA: gt_flight LIKE STANDARD TABLE OF t_flight,
	gs_flight LIKE LINE OF gt_flight,
    gt_scarr LIKE SORTED TABLE OF t_scarr,
    gs_scarr LIKE LINE OF gt_scarr.
    
 SELECT carrid fldate
 	INTO CORRESPONDING FIELDS OF TABLE gt_flight
    FROM sflight.
    
 SELECT carrid carrname
 	INTO CORRESPONDING FIELDS OF TABLE gt_flight
    FROM sflight.
  
SELECT carrid carrname
	INTO CORRESPONDING FILEDS OF TABLE gt_scarr
    FROM scarr.
    
 LOOP AT gt_flight INTO gs_flight.
 	READ TABLE gt_scarr INTO gs_scarr WITH KEY carrid = gs_flight-carrid BINARY SEARCH.
    IF sy-subrc = 0.
    	gs_flight-carrid = gs_scarr-carrid.
        MODIFY gt_flight FROM gs_flight INDEX sy-tabix.
    ENDIF.
 ENDLOOP.
 
 LOOP AT gt_flight INTO gs_flight.
 	WRITE : / 'carrid : ', gs_flight-carrid,
    'fldate : ', gs_flight-fldate,
    'carrname : ', gs_scarr-carrname.
 ENDLOOP.

-

[문제 3] 주관식 정답 비교

1. sy-tabix 

- LOOP나 READ로 검색된 인덱스 번호를 담는 시스템 변수,

- Standard Table에서 자주 사용함 

2. TRANSPORTING 이유

- 성능향상

- 필요 필드만 처리

3. LIKE TABLE OF vs TYPE TABLE OF

- TYPE TABLE OF 는 타입만 정의

- LIKE TABLE OF 는 이미 선언된 데이터 구조의 형식을 복사

4. SORTED TABLE은 PRIMARY key 기준으로 항상 정렬.

이 덕분에 Binary SEARCH가 가능하다!

5. 워크 영역 생성법

LIKE LINE OF, TYPE LINE OF

- 인터널 테이블에서 원하는 데이터를 읽으려면 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에서 접근하기 때문에 데이터베이스에서 데이터를 가져오는 전자보다 효율적이다.

1. 테이블 키를 이용한 한 줄 삭제 (WITH TABLE KEY)

DELETE gt_itab WITH TABLE KEY carrid = 'AA' connid = '1234'.

2. WHERE 조건을 이용한 여러 줄 삭제

DELETE gt_itab WHERE price < 500.

- 조건에 맞는 모든 행을 삭제함

AA 0064

AA 0064

AZ 0555... 등

3. INDEX를 이용한 한 줄 삭제 (STANDARD TABLE 전용)

- 두 번째 index를 삭제했기 때문에, col=2 col2=4가 Line에 출력되지 않는다.

4. ADJACENT DUPLICATES 삭제

- Sort by를 통해 비교 대상 필드로 정렬하고, 바로 앞뒤가 작은 경우만 삭제함. Comparing을 통해 어떤 필드를 비교해서 중복을 판단할 지 지정함

1. Table key를 이용해 한 라인 변경

- key 값을 기준으로 인터널 테이블의 라인을 변경함

- internal table이 non-unique key이고 중복된 값이 존재할 때, Modify구문이 수행할 때는 첫 라인이 변경된다.

MODIFY TABLE itab FROM wa [TRANSPORTING f1 f2..]

- modify 구문을 이용해 컬럼 col3날짜를 변경할 수 있다.

2. WHERE 조건을 이용해 여러 라인 변경

MODIFY itab FROM wa TRANSPORTING f1 f2. ... WHERE cond.

- where조건을 이용해 여러 칼럼을 조건에 추가할 수 있다.

1. ~ INTO CORRESPONDING FIELDS OF TABLE ~

- gt_itab 구조의 필드명과 sflight의 필드명이 같은 필드끼리 자동 매핑됨

- 예를 들어, gt_itab구조에 carrid, connid가 있으면 이 필드에만 들어가고 나머지는 무시됨

2. AT NEW carrid.

- gt_itab을 Loop돌릴 때, Carrid 값이 바뀌는 시점에만 실행됨

- 즉, carrid가 연속된 값 중 처음 나올 때 한 번만 수행

3. INDEX를 이용한 한 라인 변경

-index를 이용해 해당 라인의 값을 변경할 수 있음

- Index를 이용해 값을 변경하기 때문에, Standard, Sorted TYPE의 인터널 테이블에서만 사용할 수 있음

- `modify itab from wa [ index idx ] [ transporting f1 f2 ... ]`..

- collect 구문을 활용하여, 인터널 테이블의 숫자 타입 칼럼을 합산하는 기능을 수행할 수 있다.

COLLECT wa INTO itab.

- key값을 제외한 칼럼들은 Numeric Type(f, i, p)로 선언되어야 한다.

- collect 구문을 수행하면, 같은 Key값이 있을 때는 숫자 타입 칼럼을 합산하고, 없을 때는 APPEND기능을 수행한다.

- Key값이 없는 테이블은 char타입 칼럼들을 기준으로 같은 작업을 수행한다 

- 이렇게 하면 결과값은

AA 940,

AL 220이 나온다!

LIKE TABLE OF는 어떤 내부 테이블일까?

LIKE TABLE OF는 대상 변수의 “현재 내부 테이블 타입”을 그대로 따라간다는 뜻이다.

DATA: gt_source TYPE SORTED TABLE OF t_line WITH UNIQUE KEY col1.
DATA: gt_copy   LIKE TABLE OF gt_source.   " 👉 SORTED TABLE로 만들어짐

즉, gt_copy는 sorted table + unique key 구조를 그대로 따른다.

1. 한 라인 추가

- insert 구문은 Key와 Index를 이용해 인터널 테이블에 데이터를 추가할 수 있지만, append구문은 index만 이용할 수 있다.

- 즉, hashed type의 인터널 테이블에서는 사용할 수 없다.

APPEND Line TO itab.

- append를 한 후에는 시스템 변수 SY-TABIX에 인터널 테이블에 추가된 라인의 Index번호를 저장함

2. 여러 라인 추가

- insert 구문과 동일하게 인터널 테이블을 한 번에 다른 인터널 테이블로 추가할 수 있다.

APPEND lines OF itab1 TO itab2.

- itab1의 인덱스 n1~n2값을 Itab2에 추가할 수 있다.

APPEND Lines OF itab1 From n1 To n2 TO itab2.

✨ hashed table에서는 append를 사용할 수 없다!

- hash table에서는 index접근이 불가하기 때문이다. 항상 키 기반으로만 접근해야함!

- sorted도 B - A - A - C 순으로 append하니 에러가 떴다.

- 고쳐주니 제대로 잘 나온다-!

3. 인터널 테이블 타입에 따른 APPEND 효과

4. APPEND INITAL LINE

- 인터널 테이블을 빈 공간에서 미리 생성한 후, 라인을 추가할 수 있다.

APPEND INITIAL LINE TO itab
~ 
APPEND wa TO itab.

- sorted by구문을 사용하면 칼럼 f를 기준으로 DESCENDING 정렬을 수행하여 추가한다.

- 이때, Standard type의 인터널 테이블만 효력이 있으며, INITAL SIZE로 크기를 지정해야 함

APPEND wa TO itab SORTED BY f.

- 이렇게 하면 'A' 2 가 삭제된다.

- C -> B -> A 로 descending하고, initial size가 2기 때문에 A가 지워진다. 

인터널 테이블 추가하는 방법:

• insert
• append
• collect

1. TABLE KEY를 이용한 한 라인 추가 (WITH KEY)

• SORTED TABLE 또는 HASHED TABLE일 것
• WITH UNIQUE KEY로 선언되어 있어야 함
• `INSERT line into table itab`

-> insert가 성공하면, 시스템 변수 sy-subrc에 0이 저장됨

2. 여러 라인을 한 번에 추가

INSERT lines OF itab1 FROM n1 To n2 INTO TABLE itab2.

- with non-unique key col1의 의미

: col1필드가 정렬 키는 되지만 중복된 값을 가질 수 있다는 의미

선언중복 허용 조건

LIKE STANDARD TABLE OF vs TYPE STANDARD TABLE OF

1.  TYPE STANDARD TABLE OF

TYPES: ty_fruit_tab TYPE STANDARD TABLE OF ty_fruit.
DATA:  gt_fruit TYPE ty_fruit_tab.

• TYPES:는 **“타입을 정의”**하는 키워드
• 여러 변수에 재사용 가능 (복잡한 구조도 정의 가능)
• 유지보수에 좋음!
• 📌 주로 모듈화, 재사용, 선언 분리할 때 사용

2. LIKE STANDARD TABLE OF

DATA: gt_copy LIKE STANDARD TABLE OF gt_fruit.

이미 선언된 변수나 구조체를 기준으로 데이터 선언할 때 

• LIKE는 기존 변수(gt_fruit)의 구조를 참고해서 선언
• 즉, 이미 선언된 gt_fruit을 기반으로 테이블을 하나 더 만듦
• 📌 간편 복사, 임시 테이블 만들 때 사용

TYPES: BEGIN OF ty_fruit,
         name TYPE string,
         price TYPE i,
       END OF ty_fruit.

" ✅ 타입 정의
TYPES: ty_fruit_tab TYPE STANDARD TABLE OF ty_fruit.
DATA:  gt_fruit TYPE ty_fruit_tab.

" ✅ 기존 테이블 기반 새 테이블 만들기
DATA:  gt_copy LIKE STANDARD TABLE OF gt_fruit.

3. Index를 이용해 한 라인 추가

- index 구문을 이용하면 index 값 위치에 라인을 삽입할 수 있다.

- 이때는, Hashed TYPE의 인터널 테이블에는 사용이 불가하다.

- 성공 시, sy-subrc 변수는 0을, 그리고  sy-tablx변수는 index값을 반환함

INSERT line INTO itab [Index idx].

인덱스를 이용해 여러 라인도 추가할 수 있다.

INSERT lines OF itab1 INTO itab2 [Index idx].

4. 인터널 테이블 타입에 따른 INSERT

- 각각의 테이블에 insert한 후 결과다.

1. 인터널 테이블 값 할당

- 다른 변수와 같이 인터널 테이블도 MOVE 구문을 사용하여 값을 할당할 수 있다.

- 헤더라인이 있는 인터널 테이블은 헤더 라인 값만 복사됨

MOVE itab1 to itab2. " itab2 = itab1

MOVE itab1[] to itab2[]. "itab2[] = itab1[]. 구문과 동일

- 인터널 테이블 타입이 같아야 함 

- 타입이 다르면 칼럼 순서대로 값을 할당함 

- Unicode check active이 설정되어 있으면, 문자 타입과 숫자 타입 사이에 Alignment GAP이 생성되기에 에러가 발생할 수 있음

MOVE-CORRESPONDING itab1 to itab2.

- 헤더라인이 있으면 헤더 라인과 인터널 테이블이름은 같다. 이를 구분하기 위해 인터널 테이블의 BODY를 []기호를 이용해 구분한다.

- 대괄호 [] 는 헤더 라인이 있는 인터널 테이블의 Body내용을 가르킨다.

2. 인터널 테이블 초기화 

- `clear, refresh, free`

 1. CLEAR — 변수나 내부 테이블의 내용을 초기화

• 모든 타입에 사용 가능
• 변수일 경우: 기본값으로 초기화
• 내부 테이블일 경우: 데이터만 삭제, 구조는 남음

CLEAR lv_name.          " 문자열 → ''
CLEAR lv_num.           " 숫자형 → 0
CLEAR gt_itab.          " 내부 테이블 → 데이터만 삭제

- 구조(타입)은 그대로 남아 있음

- 메모리 공간을 반환(Release)하지만, 처음 메모리양을 요구한 정보는 삭제하지 않는다. 

2. REFRESH — 내부 테이블의 모든 행 삭제 (데이터만 초기화)

• CLEAR와 유사하지만 내부 테이블에만 사용
• 내부적으로는 DELETE gt_itab WHERE 1 = 1. 과 유사

REFRESH gt_itab.

- 구조는 유지

- 메모리는 남아 있음

3. FREE —  메모리까지 완전히 해제

• 내부 테이블 사용 후 메모리를 반납하고 싶을 때 사용
• 대용량 데이터 처리 후 자원 최적화에 도움됨

FREE gt_itab.

- 구조까지 삭제됨. 모든 행 데이터 삭제됨!

- 다시 쓰려면 `DATA:` 로 재선언 필요

- `READ` `APPEND` 등 다시 쓰면 에러가 발생할 수 있음

- 내부 테이블에 할당된 메모리까지 반납됨! 

=> Internal Table has no data가 뜬다!

3. 인터널 테이블 정렬

SORT itab.   " 기본 정렬: 내부 테이블 구조 기준, 기본 키 순

- Standard or Hashed type의 인터널 테이블을 정렬할 수 있음

 - sort 정렬의 기본 값은 AS이다.

- Sorted table은 테이블 자체에 정렬된 데이터를 가지고 있기 때문에 SORT명령어를 사용하면 syntax error가 뜬다.

SORT BY — 정렬 기준 지정

SORT itab BY carrid connid.

- by 뒤에 정렬할 필드 지정 가능

- 여러 필드도 가능핟/ 먼저 carrid로 정렬하고, 그 안에서 connid 기준으로 정렬됨

write 하면 AA 0017, AA 0019, BA 0018이 출력된다.

STABLE — 정렬 시 기존 순서 유지

즉, 동일한 값들끼리는 원래의 순서를 그대로 유지

SORT gs_flight STABLE BY carrid.

- STABLE 옵션은 같은 데이터라도 처음 위치한 순서가 SORT에 의해서 순번이 변경되지 않도록 하는 것.

- sort 명령어를 사용할 때 마다 sort sequence가 계속 변한다.

- stable sort 구문을 활용하면, sort sequenc가 보존된다=> 하지만 정렬시간은 더 소요되는 단점이 있다. 

- 이미 정렬된 순서가 유지되게끔 쓰기 위해서 쓰기도함 

4. 인터널 테이블 속성 알아내기 

- internal table속성을 알고싶다면 DESCRIBE구문을 사용한다.

DESCRIBE TABLE itab [LINES gv_ line] [OCCURS gv_init] [KIND gv_kind].

- LINES는 인터널 테이블에 존재하는 현재 라인수를 반환

- OCCURS는 인터널 테이블의 초기 라인 수를 반환

- KIND는 인터널 테이블의 종류를 반환

- T => Standard Table

- S => Sorted Table

- H => Hashed Table

DESCRIBE FIELD <var> LENGTH <len> IN CHARACTER MODE.

- Length : 바이트 단위

- In character mode : 문자 단위

이렇게 하면 gv_line에 gt_flight의 행의 개수를 출력할 수 있다.

=> 총 4개!

이전에 standard와 sorted를 먼저 다뤘기 때문에, hashed table만 다루고자한다-!

HASHED TABLE이란?

• 내부적으로 해시 알고리즘을 사용해서 탐색.
• 항상 UNIQUE KEY가 있어야 함.
• 탐색 속도 O(1): 항목이 수천 개여도 거의 같은 속도!
• 단점: 인덱스 기반 접근 불가 → 순서 개념이 없음!

TYPES: BEGIN OF ty_fruit,
         name  TYPE string,
         price TYPE i,
       END OF ty_fruit.

DATA: gt_fruit TYPE HASHED TABLE OF ty_fruit
                WITH UNIQUE KEY name.

DATA: gs_fruit TYPE ty_fruit.

- 순차적인 index를 가지고 있지 않음

- Standard table의 key access 속도는 인터널 테이블의 LINE수에 따라 선형 종속적으로 증가

- Sorted Table은 지수 함수로 증가

- HASHED TABLE은 정해진 KEY 필드값으로만 데이터를 찾을 수 있다!

TYPES: BEGIN OF ty_fruit,
         name  TYPE string,
         color TYPE string,
         price TYPE i,
       END OF ty_fruit.

DATA: gt_fruit TYPE HASHED TABLE OF ty_fruit
                WITH UNIQUE KEY name.   " name이 유일 키!

- 이렇게 정의하면 name 필드만 키다.

- 탐색은

`READ TABLE gt_fruit WITH KEY name = 'apple' INTO gs_fruit.   "⭕ OK` 이렇게 하면됨!

다른 key로 찾거나, index접근을 한다면 그것은 불가능!

하지만 키 필드를 여러개 지정은 가능하다.

DATA: gt_fruit TYPE HASHED TABLE OF ty_fruit
                WITH UNIQUE KEY name color.

- 이렇게 된다면 탐색은

READ TABLE gt_fruit WITH KEY name = 'apple' color = 'red' INTO gs_fruit.  "⭕ OK

 -모든 키 필드를 명시하고, 일부만 지정하면 탐색은 불가하다.

해시테이블 탐색흐름

1. 내가 찾고자 하는 키(name, 또는 name+color)를 정의한다

2. 해시 테이블이 그 키로 해시값을 계산한다

3. O(1) 시간 안에 값을 바로 찾아낸다!

READ TABLE <ITAB> WITH KEY col1 BINARY SEARCH.

=> Binary Search하는 방법!

LOOP AT itab.
	READ TABLE ITAB WITH KEY
ENDLOOP.

⬇️

SORT ITAB BY F1.
LOOP AT ITAB.
	READ TABLE ITAB WITH KEY~
    BINARY SEARCH.
ENDLOOP.

Binary SEARCH vs Sorted

- APAB은 상황에 따라 Binary SEARCH를 명시적으로 사용하기도 하지만,

보통은 SORTED or HASHED 테이블을 사용해서 자동 최적화를 함

1. STANDARD TABLE

- 기본 테이블 구조

- 선형탐색(linear search) -> 한줄씩 검사

- 느리다는 단점이 있음

2. SORTED TABLE

- 정렬된 상태 유지

- 자동으로 이진탐색 사용됨

- 빠르다! (O(longN))

3. HASHED TABLE

- 키를 기준으로 해시값 계산

- 항상 상수 시간(O(1)) 탐색

- 가장 빠름, 단 READ WITH TABLE KEY만 가능