게시글–댓글 1:N 관계 설계 정리

1. 게시글–댓글 1:N 구조

게시글과 댓글은 대표적인 1:N 관계 예시다.

• 게시글 1개에는 댓글이 0개 이상 달릴 수 있다.
  → Post (1) : Comment (N)
• 댓글 1개는 반드시 어떤 게시글 1개에 소속된다.
  → Comment는 항상 부모(Post)가 존재해야 한다.

정리하면 다음과 같다.

• 게시글 입장: 댓글은 있을 수도 있고 없을 수도 있다 (0..N)
• 댓글 입장: 게시글은 반드시 존재해야 한다 (1)

즉, 댓글은 독립 엔티티가 아니라 게시글에 종속된 엔티티다.

---

2. ERD 설계

Post

Post
--------------------------
post_id (PK)
title
content
created_at

Comment

Comment
--------------------------
comment_id (PK)
post_id (FK → Post.post_id)
body
created_at

관계

Post 1 ─── N Comment

• Comment.post_id는 NOT NULL
• Comment.post_id는 반드시 FK로 설정

댓글은 게시글이 없으면 존재할 수 없기 때문에
post_id는 NULL이 될 수 없다.

---

3. 댓글이 게시글 없이 존재할 수 없는 이유

1) 댓글은 독립 데이터가 아니다

댓글은 하나의 독립된 글이 아니라
게시글에 대한 반응 또는 부속 데이터다.

게시글이 없다면 댓글은 의미를 잃는다.

 

2) 의미 상실

댓글은 “어디에 달린 댓글인지”가 핵심이다.

post_id가 없다면:

• 어떤 게시글에 대한 댓글인지 알 수 없다.
• 데이터가 공중에 떠버린 상태가 된다.

3) 조회 및 화면 구성 불가능

대부분의 댓글 조회는 게시글 상세 화면에서 이루어진다.

예시 API:

GET /posts/{postId}/comments

postId가 없다면
어떤 게시글에 속한 댓글을 보여줄지 결정할 수 없다.

즉, ERD 구조가 그대로 API 설계와 연결된다.

 

4) 데이터 무결성 문제

게시글이 삭제되었는데 댓글이 남아 있다면
DB에는 “주인 없는 데이터”가 쌓이게 된다.

이러한 상태는 데이터 무결성을 깨뜨린다.

---

4. 무결성 보장 방식

댓글 테이블 설계 시 다음을 적용한다.

• post_id는 NOT NULL
• post_id는 FK 설정

게시글 삭제 시 정책은 다음 중 하나로 정한다.

1) CASCADE

• 게시글 삭제 시 댓글도 함께 삭제
• 가장 일반적인 방식

2) RESTRICT

• 댓글이 존재하면 게시글 삭제를 막는다
• 이력 보존이 중요한 경우 사용

---

최종 정리

게시글–댓글은 대표적인 1:N 관계이다.

• 게시글은 댓글을 0개 이상 가질 수 있다.
• 댓글은 반드시 하나의 게시글에 속해야 한다.

따라서 Comment.post_id는 NOT NULL + FK로 설계해야 하며,
게시글 삭제 시 댓글 처리 정책(CASCADE 또는 RESTRICT)을 명확히 정해야 한다.

댓글은 독립 데이터가 아니라
부모 엔티티에 종속된 데이터라는 점이 설계의 핵심이다.