경매 목록 조회 시 쿼리에 존재하는 비즈니스 로직

[apptie]

문제점

현재 경매 목록 조회 시 필터링 + 마감 임박순 정렬 시 조회할 auction의 id를 구하기 위한 쿼리는 다음과 같습니다

select
	a1_0.id 
from
	auction a1_0 
where
	a1_0.is_deleted=? 
	and a1_0.title like ? escape '!' 
order by
	case 
		when (a1_0.closing_time>?) then ? 
		else 2 
	end asc,
	a1_0.closing_time asc,
	a1_0.id desc offset ? rows fetch first ? rows only

여기서 문제가 되는 부분은 order by의 case when입니다
이 쿼리는 경매가 진행중인 상품을 우선 정렬해야 하기 때문에 사용하는 분기 처리용 기능입니다
a1_0.closing_time>?로 마감 시간과 현재 시간을 비교하고 경매가 진행중이라면 1, 경매가 마감되었다면 2를 반환하고 이 1, 2를 기준으로 오름차순 정렬을 하는 방식을 사용했습니다

이 방식은 다음과 같은 문제가 발생합니다

쿼리에 비즈니스 로직이 존재함

쿼리에 분기 처리가 들어간 순간 비즈니스 로직이 존재한다고 생각합니다
기존에는 동적으로 쿼리를 변경하는 역할을 애플리케이션이 수행하고, 그 결과로 고정된 결과를 반환하는 쿼리가 전달이 되었는데
경매 목록 조회 쿼리의 경우 case when을 통해 쿼리 자체가 동적인 결과를 만들어주고 있습니다

이러한 쿼리는 추후 비즈니스 로직이 변경될 경우 애플리케이션 뿐만 아니라 쿼리까지 변경되기 때문에 유지보수에 좋지 않다고 생각합니다
또한 이와 관련해 비즈니스 로직이 persistence layer까지 도달하게 되어 응집도까지 낮아진 상황이라고 생각합니다

애플리케이션과 연동하는 쿼리의 경우 통계성 쿼리가 아닌 이상 최대한 애플리케이션에서 수행해야 한다고 생각하므로 이를 개선해야 한다고 생각합니다

비즈니스 로직을 제대로 수행할 수 없음

이거는 이전에도 말씀드린 부분이기는 합니다

예를 들어 다음과 같은 경매가 있다고 가정하겠습니다
경매 1 : 13시에 종료
경매 2 : 14시에 종료
경매 3 : 15시에 종료
경매 4 : 4일 전에 종료
경매 5 : 10일 전에 종료
경매 6 : 90일 전에 종료

현재 시간이 12시라고 가정하면 현재 로직은 다음과 같이 정렬이 됩니다

경매 1
경매 2
경매 3
경매 6
경매 5
경매 4

경매 1 ~ 3까지는 의도대로 정렬이 되었지만 경매 6부터는 좀 애매한 부분이 있습니다
이미 경매가 종료된 경우 종료된 시간이 지금 시간과 가까운 경매를 보고 싶어할 것이라고 생각합니다
그래서 기존 요구사항도 경매가 종료된 경우는 현재 시간과 가까운 경매부터 보여주기를 요청했다고 기억하고 있습니다
만약 요구사항을 정확히 충족한다면 다음과 같은 형태가 될 것입니다

경매 1
경매 2
경매 3
경매 4
경매 5
경매 6

여기서 문제는 하나의 쿼리로 실행하다보니 이를 제어할 수단이 없다는 것입니다
현재 시간이 마감 시간보다 앞서 있으면 asc(), 아니라면 desc()로 정렬 조건 자체를 변경해야 하기 때문입니다
이는 쿼리로는 수행할 수 없었습니다
강제로 정렬용 key같은걸 만들수도 있겠지만 이건...굳이스러웠습니다
(만약 비즈니스 로직이 쿼리에 존재하지 않았다면 mysql virtual column을 만들고 거기에 인덱스를 걸었을 것 같습니다)

그러므로 이를 개선해야 된다고 생각합니다

해결방안

경매 진행중과 경매가 종료된 목록을 따로 조회하면 된다고 생각했습니다
이를 표현하기 위해 PR을 대충 수도코드로 작성했습니다

참고자료

김영한님 답변 - 요약하면 DB에 분기처리 하지말고 최대한 애플리케이션으로 빼라고 볼 수 있을 것 같습니다
비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유

[JJ503]

오 종료된 경매 순서에 대해서는 미처 생각하지 못했네요...!
궁금한 점들이 pr과 겹치거나 하는 부분들이 있어 pr에 함께 작성했습니다!

디스커션 덕분에 더 잘 이해했습니다 지토 👍