반응형
1. JPA + JPQL 사용 (현재 코드 방식)
장점
- JPA의 객체 매핑을 그대로 활용 가능 → 유지보수가 쉬움.
- JPQL이므로 DBMS 독립적 → 다른 DB로 변경 시 대응이 쉬움.
- DTO 변환을 자동으로 해줌 (new DTO()).
단점
- 복잡한 SQL을 JPQL로 작성하기 어려움 → 특히, CASE, GROUP BY, SUM(), UNION, JOIN이 많을 때 불편.
- 특정 DB 함수 (DATE_FORMAT, IFNULL) 등은 JPQL에서 지원이 제한적.
언제 쓰면 좋을까?
- 복잡한 SQL이 필요 없고, 유지보수성과 JPA의 장점을 활용하고 싶을 때.
2. Native Query 사용 (JPQL 대신)
장점
- SQL 최적화 가능 → 실행 계획 튜닝, INDEX 최적화, DBMS별 최적 SQL 작성 가능.
- 복잡한 JOIN, GROUP BY, 윈도우 함수 등 활용 가능 → SUM(), CASE, RANK() 등.
단점
- DBMS 의존적 → 다른 DBMS로 변경 시 SQL 수정이 필요.
- DTO로 직접 변환해야 함 → Object[]을 매핑하는 과정 필요.
언제 쓰면 좋을까?
- 고성능 SQL이 필요할 때 (대량 데이터 조회, 복잡한 통계 처리 등).
- JPA만으로 최적화가 어려울 때 (ex: GROUP BY, SUM, JOIN 등).
3. MyBatis 사용
장점
- 동적 SQL 지원 (<if>, <foreach> 가능) → JPA보다 유연함.
- SQL을 직접 최적화 가능 → 인덱스 튜닝, 복잡한 JOIN 최적화 가능.
- 별도의 DTO 매핑이 쉬움 → resultMap을 활용해 객체 매핑 가능.
단점
- JPA의 장점을 활용할 수 없음 → 유지보수가 어렵고, 엔티티 기반 개발이 어려움.
- SQL 관리가 복잡해질 수 있음 → XML 기반이므로 코드 관리 부담 증가.
언제 쓰면 좋을까?
- 복잡한 동적 SQL이 많을 때 (<if>, <choose> 사용).
- JPA로 성능이 잘 안 나올 때 (쿼리 튜닝 필요).
- 기존 프로젝트가 MyBatis 기반일 때.
결론: 현업에서 많이 쓰는 방식
방법특징장점단점추천 상황
| JPQL | JPA 기반 객체 쿼리 | DB 독립적, 유지보수 용이 | 성능 최적화 어려움 | 일반적인 CRUD, 단순 통계 |
| Native Query | SQL 직접 실행 | 성능 최적화 가능 | DBMS 종속적, DTO 매핑 필요 | 복잡한 SQL, 대량 데이터 조회 |
| MyBatis | XML 기반 SQL 매핑 | 동적 SQL 지원, 성능 최적화 | JPA와 분리됨, 유지보수 부담 | 동적 SQL이 많은 경우 |
Best Practice (상황별 추천)
1 .일반적인 CRUD (JPA의 장점을 활용)
- JPQL 사용
- 유지보수성이 중요한 경우.
2. 복잡한 통계 조회 (GROUP BY, SUM, JOIN 최적화)
- Native Query 사용
- 성능 최적화가 필요할 때.
3. 복잡한 동적 SQL (다양한 조건 검색)
- MyBatis 사용
- <if>, <foreach>를 활용해야 할 때.
한 줄 요약!
➡ "일반적인 개발은 JPA + JPQL 사용, 성능이슈 발생 시 Native Query로 최적화, 동적 SQL이 많으면 MyBatis를 활용!"
반응형