inflearn logo
강의

강의

N
챌린지

챌린지

멘토링

멘토링

N
클립

클립

로드맵

로드맵

지식공유

김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴

UPSERT 최적화

DELETE -> SELECT 질문 드립니다.

48

index

작성한 질문수 10

0

안녕하세요

 

단건데이터(ex: 로그) 처리의 경우에는 크게 고민하지 않고 MERGE를 사용하여 처리하고 있습니다.

 

하지만 10~20건 이상의 데이터셋이 들어오는 경우에는 어떤 방식으로 처리하는 것이 더 적절한지 고민이 되어 질문드립니다.

 

  1. 데이터 DELETE -> INSERT

     

    • 2번의 쿼리 수행(또는 BEGIN으로 1번에 수행)

       

  2. 데이터 STATE (I, U, D 등)를 활용하는 방식

     

    • 화면에서 데이터에 INSERT / UPDATE / DELETE 상태값을 기반으로 서버에서 DELETE 1회, INSERT 1회, UPDATE N회를 수행


실무에서는 작업 공수 문제로 1번 방식(DELETE -> INSERT)을 선택하는 경우가 많았습니다.

 

다만 이 방법을 사용하면서

데이터 관리, 유지보수, 성능 측면에서 어떤 방식이 더 바람직한 선택인지 궁금합니다.

sql mysql dbms/rdbms 소프트웨어-설계 SQLD

답변 1

0

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. index님께서 질문해주신 데이터 처리 방식에 대한 내용에 대해 설명드리겠습니다.

여러분이 언급한 두 가지 데이터 처리 방법에 장단점이 있어 실무에서 상황에 따라 선택이 다를 수 있습니다.

  1. 데이터 DELETE -> INSERT 방식:

    • 장점: 개발이 쉽고, 구현 시간이 비교적 짧습니다. 특히 데이터의 수정이 자주 필요한 상황에서는 간단한 형태로 데이터를 재처리할 수 있습니다.
    • 단점: DELETE 연산은 테이블에서 여러 데이터 블록을 지우게 되어 DB 블록 낭비가 발생할 수 있고, 이로 인해 성능에 영향을 줄 수 있습니다. 또한, 기존 데이터의 CREATE_DATE 정보 손실로 인해 데이터의 이력을 추적하기 어려워질 수 있습니다.
  2. STATE 기반 처리 방식:

    • 장점: 데이터의 이력을 보다 명확하게 추적할 수 있습니다. STATE 필드로 특정 데이터가 INSERT, UPDATE, DELETE 상태인지를 관리할 수 있어 데이터의 변경 히스토리를 관리하기 용이합니다.
    • 단점: 구현이 더 복잡하고, 여러 번의 데이터 수정이 필요한 경우 추가적인 로직이 필요할 수 있어 개발 공수가 증가할 수 있습니다.

결론적으로, 데이터의 유지보수와 성능을 중요시 여긴다면 STATE 기반의 방식이 더 바람직할 수 있습니다. 이는 데이터의 변경 이력 추적과 DB 성능 측면에서 더 유리할 수 있습니다. 하지만 개발 시 작업 공수를 고려할 때는 DELETE -> INSERT 방식도 충분히 활용 가능하며, 특히 시스템의 CRUD가 빈번히 일어나는 경우라면 더욱 고려해볼 수 있습니다.

관련된 실무 사례들을 추가로 알고 싶으신 경우, 다음 질문 URL을 참고하시길 바랍니다:
- Delete 메소드에 관한 질문

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

실제 FK제약조건을 설정하지 않는이유

0

30

2

히스토리 관련 질문

0

57

2

통계 데이터 수정 질문

1

63

2

공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?

0

133

2

상속 관계 모델링의 적용 기준 질문

0

75

1

TTL 캐싱에 대한 질문

0

78

1

공통 코드 사용시 컬럼 타입 설정

0

83

1

history_creted_at과 valid_from

1

65

2

함수 기반 인덱스 (Function-Based Index)

0

68

1

추후 강의 질문있습니다

0

124

2

실무 통계 질문(고민) 드립니다..!

0

91

2

Json 컬럼의 객체 맵핑

0

64

1

[Deprecated] 오타 제보

0

86

1

오타 제보

0

73

2

category_path 테이블에서 idx_descendant 인덱스를 생성하는 이유가 궁금합니다

0

96

2

물리적으로 외래 키 제약 조건을 설정하지 않을 때

0

97

1

`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경

1

84

1

common_code_detail의 code 변경 가능성

1

112

1

[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보

0

87

1

이미 문자열 타입인 컬럼을 캐스팅하는 이유

0

106

2

계층 구조 모델링 기타 방법들

0

106

1

섹션 9의 퀴즈가 영어로 출력되요.

0

106

2

섹션 6 SOFT DELETE) UNIQUE 제약 조건 + 가상 컬럼

0

77

1

섹션2 공통 코드) 애플리케이션 ENUM을 API에 그대로 노출한다면?

0

126

1