ABAP 클린 코드 - 테이블 [3-1]

“올바른 테이블 유형을 사용하라”는 ABAP에서 테이블을 정의할 때, 데이터의 성격과 사용 목적에 맞는 적절한 테이블 유형을 선택하라는 중요한 프로그래밍 원칙입니다. ABAP에는 여러 가지 테이블 유형이 있으며, 각각의 특성에 맞는 올바른 테이블 유형을 선택하면 성능을 최적화하고 코드의 가독성 및 유지보수성을 높일 수 있습니다.

1. 표준 테이블 (Standard Table, STANDARD TABLE)

• 특징: 표준 테이블은 가장 기본적인 테이블 유형입니다. 테이블의 항목들이 순차적으로 저장되며, 인덱스 기반으로 접근할 수 있습니다.
• 용도: 데이터가 순차적으로 삽입되고, 키가 없는 경우 사용됩니다. 읽기 작업에서 키 기반의 빠른 검색이 필요하지 않을 때 적합합니다.
• 검색 성능: 키 검색 시 순차 검색이 이루어지므로, 데이터가 많을 경우 성능이 떨어질 수 있습니다.

* Standard Table
DATA: lt_standard_table TYPE STANDARD TABLE OF mara WITH EMPTY KEY.

 

2. 정렬 테이블 (Sorted Table, SORTED TABLE)

• 특징: 정렬 테이블은 삽입 시 자동으로 지정된 키에 따라 정렬됩니다. 삽입과 동시에 정렬이 유지되므로, 검색 시 이진 검색(binary search)을 사용하여 성능이 향상됩니다.
• 용도: 데이터를 키 기반으로 자주 검색해야 하며, 데이터가 자동으로 정렬된 상태로 유지되어야 할 때 사용됩니다. 예를 들어, 로그 데이터나 이력 데이터 관리에 적합합니다.
• 검색 성능: 이진 검색이 사용되므로, 대용량 데이터에서도 빠른 검색이 가능합니다.

* Sorted Table
DATA: lt_sorted_table TYPE SORTED TABLE OF mara WITH UNIQUE KEY matnr.

 

3. 해시 테이블 (Hashed Table, HASHED TABLE)

• 특징: 해시 테이블은 키를 기반으로 해시 알고리즘을 사용하여 데이터를 관리합니다. 이 때문에 검색이 매우 빠르지만, 테이블을 순차적으로 읽거나 정렬하는 작업은 불가능합니다.
• 용도: 키 기반의 매우 빠른 검색이 필요하고, 순차적인 접근이 필요 없는 경우에 적합합니다. 데이터의 고유성이 중요할 때, 예를 들어 유일한 식별자를 기반으로 데이터를 조회하는 경우에 적합합니다.
• 검색 성능: 검색 성능이 매우 뛰어나지만, 순차적인 데이터 접근이 불가능합니다.

* Hashed Table
DATA: lt_hashed_table TYPE HASHED TABLE OF mara WITH UNIQUE KEY matnr.

 

올바른 테이블 유형 선택 기준.

 

1. 데이터 검색 방식

• 순차 검색이 많은 경우: 표준 테이블(STANDARD TABLE)이 적합합니다.
• 키 기반의 빠른 검색이 필요한 경우: 해시 테이블(HASHED TABLE) 또는 정렬 테이블(SORTED TABLE)을 선택합니다.

2. 데이터 삽입 및 정렬

• 삽입 시 자동 정렬이 필요한 경우: 정렬 테이블(SORTED TABLE)을 사용합니다.

3. 데이터의 고유성

• 고유한 키를 필요로 하는 경우: 정렬 테이블(SORTED TABLE) 또는 해시 테이블(HASHED TABLE)이 적합하며, 키의 고유성을 유지할 수 있습니다.

4. 순차 접근

• 순차적인 데이터 접근이 필요한 경우: 표준 테이블(STANDARD TABLE)이 적합합니다.
• 순차 접근이 불필요하고, 키 기반 검색만 필요한 경우: 해시 테이블(HASHED TABLE)이 가장 적합합니다.

“기본 키 사용을 피하라”는 지침은 특정 상황에서 기본 키(primary key)를 무조건 사용하지 말라는 의미보다는, 기본 키를 설계할 때 신중을 기하라는 경고로 이해할 수 있습니다. 이 지침은 특히 데이터베이스 설계 및 테이블 관리에 있어 중요한 의미를 가집니다.

 

기본 키란?

기본 키는 데이터베이스 테이블에서 각 행(row)을 고유하게 식별할 수 있는 하나 이상의 열(column)로 구성됩니다. 기본 키는 중복되지 않으며, NULL 값을 가질 수 없습니다. 기본 키를 통해 테이블 내의 특정 데이터를 빠르고 정확하게 검색할 수 있습니다.

 

1. 비즈니스 의존 키를 피하라.

• 비즈니스 의존 키(예: 사회보장번호, 이메일 주소 등)를 기본 키로 사용하는 것은 위험할 수 있습니다. 비즈니스 데이터는 시간이 지남에 따라 변경될 수 있고, 변경된 데이터는 기본 키의 유일성을 위협할 수 있습니다. 또한, 이러한 데이터가 변경될 경우 기본 키를 기반으로 하는 모든 연관 테이블에서 문제가 발생할 수 있습니다.

* 잘못된 패턴 - Email이 기본 키일 경우
DATA: lt_customers TYPE SORTED TABLE OF zcustomer WITH UNIQUE KEY email.

Email을 기본 키로 사용하는 것은 문제가 될 수 있습니다. 사용자가 이메일 주소를 변경하는 경우, 이 기본 키는 더 이상 유일하지 않을 수 있습니다.

 

2. 자연 키보다 대체 키를 선호하라.

• 자연 키(즉, 실제 비즈니스 데이터를 포함하는 키)를 기본 키로 사용하는 대신, 대체 키(대부분 자동 증가되는 숫자 또는 UUID)를 사용하는 것이 좋습니다. 대체 키는 비즈니스 로직과 무관하게 유일성을 보장하며, 데이터의 변경 가능성을 최소화합니다.

* UUID 처럼 임의의 값으로 키를 대체 하는 잘된 패턴
DATA: lt_customers TYPE SORTED TABLE OF zcustomer WITH UNIQUE KEY customer_id.

 

3. 복합 키 사용을 신중히 고려하라.

• 여러 열을 조합하여 복합 키를 구성할 때, 이러한 키가 실제로 고유성을 보장하는지, 유지보수가 용이한지를 신중하게 고려해야 합니다. 복합 키는 설계와 관리가 복잡해질 수 있으며, 이로 인해 성능 저하나 데이터 무결성 문제가 발생할 수 있습니다.

적절한 기본 키 설계의 중요성

 

기본 키는 데이터베이스 테이블의 성능과 데이터 무결성을 유지하는 데 중요한 역할을 합니다. 그러나 잘못된 기본 키 설계는 다음과 같은 문제를 초래할 수 있습니다.

1. 데이터 무결성 문제: 기본 키가 비즈니스 로직에 종속되거나 변경 가능한 데이터를 포함하는 경우, 시간이 지남에 따라 데이터 무결성이 손상될 수 있습니다.
2. 성능 저하: 복합 키나 비즈니스 의존 키는 인덱싱 및 검색 성능을 저하시킬 수 있으며, 대규모 데이터베이스에서 성능 문제가 발생할 수 있습니다.
3. 유지보수 어려움: 기본 키로 사용된 열이 변경되거나 비즈니스 로직이 변경될 경우, 이로 인해 발생하는 연쇄적인 변경이 테이블과 관련된 모든 시스템에 영향을 미칠 수 있습니다.

“APPEND TO보다 INSERT INTO TABLE을 사용하라”는 ABAP 코딩에서 리스트나 테이블에 데이터를 추가할 때, 보다 명확하고 안전한 방법을 사용하라는 지침입니다. 이 지침은 데이터 추가 시 의도치 않은 오류를 방지하고, 코드의 가독성과 유지보수성을 높이기 위한 것입니다.

APPEND TO와 INSERT INTO TABLE의 차이점.

 

1. APPEND TO

• APPEND TO 명령은 표준 내부 테이블의 마지막에 새로운 항목을 추가하는 데 사용됩니다.
• 이 명령은 주로 순차적으로 데이터를 추가할 때 사용되며, 내부 테이블의 끝에 항상 추가됩니다.
• 제한사항: APPEND TO는 표준 테이블(STANDARD TABLE)에서만 사용할 수 있습니다. 정렬 테이블(SORTED TABLE)이나 해시 테이블(HASHED TABLE)에서는 사용할 수 없습니다.

* APPEND TO
DATA: lt_table TYPE TABLE OF string,
      lv_value TYPE string.

lv_value = 'Hello World'.
APPEND lv_value TO lt_table.

 

2. INSERT INTO TABLE

• INSERT INTO TABLE 명령은 내부 테이블의 특정 위치에 데이터를 삽입하거나, 특정 조건을 만족하는 위치에 데이터를 삽입하는 데 사용됩니다.
• INSERT INTO TABLE은 표준 테이블(STANDARD TABLE)뿐만 아니라 정렬 테이블(SORTED TABLE)과 해시 테이블(HASHED TABLE)에서도 사용할 수 있습니다.
• 장점: INSERT INTO TABLE은 테이블 유형에 관계없이 데이터를 안전하게 추가할 수 있으며, 데이터 중복이나 정렬 조건 등을 자동으로 처리할 수 있습니다.

* INSERT INTO TABLE
DATA: lt_table TYPE SORTED TABLE OF string WITH UNIQUE KEY table_line,
      lv_value TYPE string.

lv_value = 'Hello World'.
INSERT lv_value INTO TABLE lt_table.

 

왜 INSERT INTO TABLE이 더 좋은 선택일까?

1. 유연성: INSERT INTO TABLE은 모든 유형의 내부 테이블(표준, 정렬, 해시 테이블)에서 사용할 수 있습니다. 반면, APPEND TO는 표준 테이블(STANDARD TABLE)에서만 사용할 수 있습니다.
2. 자동 중복 처리: INSERT INTO TABLE은 정렬 테이블(SORTED TABLE)이나 해시 테이블(HASHED TABLE)의 경우, 중복된 키가 있는 데이터를 삽입할 때 자동으로 오류를 발생시켜 중복을 방지할 수 있습니다. 반면, APPEND TO는 단순히 데이터를 추가할 뿐 중복 처리나 정렬 조건을 고려하지 않습니다.
3. 명확한 의도: INSERT INTO TABLE은 데이터를 삽입하는 위치와 조건을 명확하게 표현할 수 있어 코드의 의도가 더 분명해집니다. 반면, APPEND TO는 항상 테이블의 끝에 데이터를 추가하므로, 의도와 다른 결과를 초래할 수 있습니다.
4. 성능 최적화: 정렬 테이블(SORTED TABLE)이나 해시 테이블(HASHED TABLE)에서 INSERT INTO TABLE을 사용하면, 테이블의 성능 특성을 활용하여 더 효율적으로 데이터를 삽입할 수 있습니다. APPEND TO는 표준 테이블(STANDARD TABLE)에서만 작동하므로, 특정 상황에서 성능상의 이점을 놓칠 수 있습니다.