진행했던 프로젝트의 댓글 설계 구조를 살펴보자면
현재 설계에서는 댓글이 특정 리뷰(review_id)에 종속되는 구조이므로, 리뷰에 대한 1 Depth(1단계)만 지원된다.
즉, 리뷰에 대한 댓글은 달 수 있지만, 대댓글(댓글에 대한 댓글)은 지원되지 않는 구조이다.
대댓글을 작성하려면 어떻게 해야할까?
1. parent_id를 활용한 계층형 댓글 구조(가장 많이 사용 한다)
대댓글을 지원하기 위해 parent_id 컬럼을 추가하는 방법이다.
parent_id가 NULL이면 일반 댓글, 값이 있으면 해당 댓글의 대댓글로 설정하는 것이다.
- 댓글 저장 로직에서도
parent_id를 체크하여 부모 댓글이 존재하는지 확인한 후 저장해야 한다. ON DELETE CASCADE를 설정하면 부모 댓글 삭제 시 대댓글도 자동 삭제할 수 있다.- 트리 구조를 표현하기 쉬우며, 대부분의 서비스에서 이 방식을 사용한다.
장점
- 구현이 간단하고 확장성이 좋다.
- 대부분의 서비스에서 사용하는 방식이다.
- 트리 구조로 데이터 조회 가능하다.
- 부모 댓글이 삭제되면 대댓글도 삭제 가능하다.(ON DELETE CASCADE)
단점
- 뎁스(
Depth)가 깊어질 경우 쿼리가 복잡해진다. (재귀 쿼리 필요) - 무한 뎁스 지원이 어렵다. (일반적으로 2~3 뎁스까지만 허용)
2. group_id + depth를 활용한 정렬 기반 계층 구조
대댓글이 많아질 경우, 정렬을 고려해야 한다면 group_id 와 depth 필드를 추가하는 방식도 있다.
group_id: 부모 댓글ID를 저장하여 그룹화depth: 댓글의 깊이를 저장 (0 = 부모 댓글, 1 = 첫 번째 대댓글, 2 = 두 번째 대댓글)- 댓글을 조회할 때
group_id ASC,depth ASC,created_at ASC로 정렬하면 트리 구조를 유지할 수 있다.
장점
- 정렬이 쉽다. (
ORDER BY group_id,depth, created_at) - 트리 구조를 유지하면서 쿼리 성능이 안정적이다.
단점
- 댓글 추가할 때
group_id를 설정해야 하는 번거로움이 있다. - 데이터 정합성을 유지하려면 트랜잭션 관리가 필요하다.
