피해야할 SQL 안티패턴들

1. 과도하게 복잡한 CASE WHEN 구문

빠른 개발을 위해 하나의 VIEW에만 CASE WHEN 로직을 다량으로 추가하는 것은 장기적으로 안티패턴에 해당함

이는 중복 로직 복사/붙여넣기, 해석 불일치 문제를 유발하여 전체 쿼리 환경을 난잡하게 만듦

 

- 해결책

차원 테이블 (dimension table) 또는 공용 뷰를 별도로 만들어 재사용성을 확보

 

 

2. 인덱스 컬럼에서 함수 사용

"WHERE UPPER(name) = 'ABC'" 처럼 인덱스가 걸린 함수에 함수를 적용하면 인덱스 효율이 사라짐 (full scan 발생 가능)

 

- 해결책

함수 적용 컬럼을 별도로 인덱싱하거나 입력 값을 변환해 쿼리 조건을 단순화

 

 

3. 뷰에서 SELECT * 사용

SELECT * 을 사용하면 편해보이지만 스키마가 변경되면 뷰가 쉽게 깨질 수 있음

불필요한 컬럼까지 포함돼 의도치 않은 의존성 및 성능 문제가 발생

 

- 해결책

SELCT 시 명시적으로 컬럼을 선택해야함

 

 

4. DISTINCT 남용으로 중복 문제 "해결"

잘못된 JOIN으로 중복된 결과가 발생할 때 SELECT DISTINCT로 임시 해결하는 것은 데이터 무결성 문제를 감춤

근본 원인은 조인 조건의 불완전함이나 관계 정의(1:1, N:N) 오류

 

- 해결책

JOIN 로직 보강을 통해 관계 정의를 명확화하고 집계나 리포트 이전에 관계 정합성을 확보

 

 

5. 뷰 중첩 (Excessive View Later Staking)

여러 팀이 기존 뷰를 재활용하여 새로운 뷰를 계속 쌓을 경우 종속성 체인이 복잡해지고 성능이 급격히 저하됨

 

- 해결책

주기적으로 변환 로직을 평탄화(flatten)하고 복잡한 연산은 명확한 베이스 뷰나 테이블로 머티리얼라이즈(matrialize) 하는 전략이 필요함

 

 

6. 과도한 깊이의 서브쿼리

3~4단계 이상으로 깊게 중첩된 서브쿼리는 가독성을 떨어트리고 디버깅을 어렵게 함

 

- 해결책

CTE (Common Table Expression)를 활용하면 논리적 단계 구분이 쉬워지고 쿼리의 명확성이 높아짐

 

 

 

 

 

Reference

https://news.hada.io/topic?id=23756

피해야 할 SQL 안티패턴들 | GeekNews