[내일배움캠프Spring-69일차] 최종 프로젝트 기획단계 이슈

✅ 공통으로 사용되는 Category 테이블 분리 여부

"자주 사용되는 테이블에서 target_type + target_id 형태로

user 또는 club 등을 참조하는 방식이 좋은가?"

1. 처음엔 하나의 테이블로 시작해도 OK

• 지금은 User, Club 등이 모두 비슷한 의미의 카테고리를 가진다고 판단된다면,
• 공통적인 개념으로 추상화해서 하나의 테이블로 관리하는 것이 가능하다.
• 즉, target_type + target_id로 접근해도 괜찮다.

---

2. 하지만 도메인 관점에서 반드시 고민해봐야 한다

• 단순히 데이터 구조나 쿼리의 편의성만 보고 결정하면 안 됨.
• 도메인 자체가 다르다면, 의미 있는 분리가 필요하다.

예시:

• UserCategory: 유저의 관심사, 개인적인 선택
• ClubCategory: 팀 단위의 목적이나 활동 주제
• → 이런 것들이 기능적, 의미적으로 다른 역할을 한다면 나눠야 한다.

---

3. 도메인 확장성과 독립성도 고려해야 함

• 시스템이 확장될수록 User, Club, Category 등은 별개의 도메인으로 커질 수 있음.
• 결국에는 DB 자체가 분리되거나,
• 서로 상호 참조가 불가능한 구조가 되어야 할 수 있다.

→ 이럴 때 하나의 테이블에 target_type으로 묶어두면 의존성이 꼬이고, 유지보수 어려워짐

---

4. 카테고리가 확장될 가능성 vs 커스터마이징

• 유저의 관심 카테고리는 VOC나 피드백에 따라 다채로워질 수 있음→ 유저용, 클럽용 카테고리 분리 필요
• → 유저가 자신의 토픽을 만들어 내는 식의 커스터마이징도 고려된다면

 

✅ 대댓글 처리 방식 문제

대댓글을 별도 테이블로 분리할까?아니면 댓글 테이블에 parent_id 컬럼을 넣고,      null이면 원댓글, 값이 있으면 대댓글로 판단할까?

---

1. 대댓글 테이블을 따로 만들 이유가 명확하지 않다면, 분리하지 말 것

• 테이블을 쪼개는 건 언제나 복잡도를 높이는 일.
• *“대댓글은 댓글과 본질적으로 다른 데이터다”**라는 명확한 차이가 있을 때만 쪼개야 함.
  • 예: 대댓글에는 사진이 들어가고, 댓글은 텍스트만 있음 → 분리 필요.

2. 구조적으로 차이가 없다면 하나의 테이블로

• parent_id 방식으로 설계하면 트리 구조를 표현할 수 있고, 대댓글도 깔끔하게 관리 가능.
• 댓글 == 원댓글 (parent_id is null)
• 대댓글 == 댓글에 대한 자식 (parent_id = 댓글의 id)

---

추가적인 조언

3. Null을 쓰는 이유 (DB 관점)

이유 설명

❗ 0 사용 지양	0은 진짜 ID처럼 보일 수 있어 오해의 소지가 있음
✅ null 사용	"부모 없음"을 명확하게 표현 (= 루트 댓글)
✅ DB 공간 최적화	nullable 필드는 null이면 저장공간을 더 적게 씀
✅ 쿼리 직관성	WHERE parent_id IS NULL로 루트 댓글만 쉽게 조회

---

4. 최종 정리 (튜터님 조언 기반)

항목 추천

테이블 개수	✅ 하나로 통합 (comment)
대댓글 구조	✅ parent_id 컬럼 사용 (nullable)
대댓글 구분	parent_id IS NULL → 루트 댓글, parent_id IS NOT NULL → 대댓글
DB 컬럼 타입	parent_id BIGINT NULL (nullable 설정 명시)
대댓글만 다른 기능 (예: 이미지 첨부 등)	❌ 있다면 분리 고려 (ex. reply_comment 테이블 분리)