ERD 설계 사고 복습 정리

1. user 테이블이 생긴 이유

서비스를 사용하는 사람을 식별하기 위해 존재한다.

구체적으로는 다음을 담당한다.

• 사용자 식별 (user_id)
• 인증 정보 관리 (로그인, 토큰 등과 연결)
• 인가 판단의 기준 제공 (권한, 역할 등)
• 사용자 프로필 정보 저장

즉, user 테이블은
“누가 이 서비스를 사용하는가”를 정의하는 엔티티다.

---

2. posts 테이블이 생긴 이유

사용자가 작성한 콘텐츠를 저장하고 관리하기 위해 존재한다.

posts 테이블은 다음을 책임진다.

• 게시글의 제목과 내용 저장
• 작성자(user_id)와의 관계 관리
• 게시 상태(status) 관리 (PUBLISHED, DRAFT 등)
• 조회수(view_count) 관리
• 수정/삭제 이력 관리(updated_at, deleted_at)

posts는 사용자 행위의 결과물인 “콘텐츠”를 관리하는 엔티티다.

---

3. comments 테이블이 생긴 이유

게시글에 대한 의견을 저장하기 위해 존재한다.

comments는 다음을 책임진다.

• 어떤 게시글(post_id)에 달린 댓글인지 관리
• 누가(user_id) 작성했는지 관리
• 댓글 내용 저장
• 생성/삭제 시각 관리
• 대댓글 확장을 위한 계층 구조(parent_comment_id 등)

---

4. 댓글을 posts에 넣지 않고 분리하는 이유

댓글은 게시글의 일부처럼 보이지만,
구조적으로는 독립 엔티티다.

분리하는 이유는 다음과 같다.

1. 댓글은 여러 개가 존재할 수 있다.
   → 반복 컬럼이 되므로 1NF 위반
2. 댓글은 수정/삭제/정렬/페이징이 필요하다.
3. 대댓글 확장 가능성이 있다.
   → 자기참조 구조 필요
4. 댓글은 독립적인 생명주기를 가진다.
   → 게시글과 별도로 생성, 수정, 삭제된다.

따라서 댓글은 posts 안에 넣는 것이 아니라,
별도 테이블로 분리해야 한다.

---

5. 중간 테이블이 필요한 이유

중간 테이블은 N:M 관계를 데이터베이스에서 표현하기 위해 존재한다.

예시

• 주문 ↔ 상품
• 게시글 ↔ 태그
• 사용자 ↔ 좋아요

데이터베이스는 N:M 관계를 직접 표현할 수 없기 때문에
두 개의 1:N 관계로 분해해야 한다.

그 역할을 하는 것이 중간 테이블이다.

중간 테이블에는
“두 엔티티의 관계에서만 의미 있는 정보”를 저장한다.

---

6. ERD 보고 바로 API 3개 떠올리기 연습

ERD를 보면 바로 CRUD가 떠올라야 한다.

posts 기준으로 생각해보면 다음 3개가 기본이다.

1. 생성
   POST /posts
   → 게시글 작성
2. 목록 조회
   GET /posts
   → 게시글 리스트 조회
3. 상세 조회
   GET /posts/{id}
   → 특정 게시글 상세 조회

여기에 자연스럽게 다음이 확장된다.

• PATCH /posts/{id} → 수정
• DELETE /posts/{id} → 삭제

즉, 테이블 책임을 1문장으로 정의하면
API 구조가 자동으로 따라 나온다.

---

최종 정리

테이블은 단순히 데이터를 저장하기 위해 존재하는 것이 아니다.

각 테이블은 하나의 책임을 가지며,
그 책임을 명확히 분리하기 위해 설계된다.

• user는 사용자 식별과 인증/인가의 기준
• posts는 콘텐츠 관리
• comments는 게시글에 대한 반응 관리
• 중간 테이블은 N:M 관계 표현

ERD를 볼 때는 “이 테이블이 왜 존재하는가?”를 먼저 생각하고,

그 다음 “이 책임에서 어떤 API가 나오는가?”를 연결해야 한다.

테이블은 데이터 저장용 구조가 아니라, 책임을 분리하기 위한 설계 결과물이다.