努力未来

ERD 분석하기

홍서현
홍서현Jul 3, 2025
ERD 분석하기

본격적인 졸업 프로젝트 개발 시작 전에 기존 코드를 리펙토링 하고자 ERD를 정리하여 그려보았다.

⚠️ 성능 개선 포인트

1. FK에 인덱스 누락 시 성능 저하 가능

아래 필드들은 조회 시 JOIN이 많을 수 있음 → 반드시 인덱스 필요:

테이블컬럼개선
likesuser_id, board_id✅ 인덱스 필요
board_applicationuser_id, board_id✅ 인덱스 필요
noticeboard_id, writer_id✅ 인덱스 필요
notice_commentnotice_id, user_id✅ 인덱스 필요
verificationuser_id✅ 인덱스 필요
reportreporter_id, reported_user_id, reported_board_id✅ 인덱스 필요

✅ 해결 방법: 아래처럼 인덱스 추가

CREATE INDEX idx_board_application_user ON board_application(user_id);
CREATE INDEX idx_likes_board_user ON likes(board_id, user_id
sql

2. 복합키 테이블 → PK 명확화 추천

likes, board_interest_tags, user_interest_tag 같은 테이블에서:

  • 현재 id 없이 복합키(user_id, board_id)로 보임
  • → 이는 설계적으로는 좋지만, 일부 ORM/JPA 사용 시 @EmbeddedId를 요구하거나 JOIN 시 불편함

✅ 선택지:

  • 그대로 유지 (JOIN 성능은 좋음)
  • 또는 surrogate key(id) 추가 + 유니크 제약 유지

3. 공지사항 1:1 제약 없음

  • Board당 Notice 1개만 작성 가능해야 한다면:
    • notice.board_idUNIQUE 제약을 반드시 추가해야 함
ALTER TABLE notice ADD CONSTRAINT unique_board UNIQUE (board_id);
sql

🔚 종합 평가

항목점수평가
정규화⭐⭐⭐⭐⭐완벽
관계 설계⭐⭐⭐⭐☆명확하나 일부 제약 없음 (공지사항 1:1 등)
성능 최적화⭐⭐⭐☆인덱스 추가 필요
확장성/유지보수성⭐⭐⭐⭐⭐우수
전체 점수4.5 / 5.0실무급 좋은 설계지만 인덱싱, 일부 제약만 보완하면 완벽