본격적인 졸업 프로젝트 개발 시작 전에 기존 코드를 리펙토링 하고자 ERD를 정리하여 그려보았다.
⚠️ 성능 개선 포인트
1. FK에 인덱스 누락 시 성능 저하 가능
아래 필드들은 조회 시 JOIN이 많을 수 있음 → 반드시 인덱스 필요:
테이블 | 컬럼 | 개선 |
likes | user_id , board_id | ✅ 인덱스 필요 |
board_application | user_id , board_id | ✅ 인덱스 필요 |
notice | board_id , writer_id | ✅ 인덱스 필요 |
notice_comment | notice_id , user_id | ✅ 인덱스 필요 |
verification | user_id | ✅ 인덱스 필요 |
report | reporter_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
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_id
에 UNIQUE 제약을 반드시 추가해야 함
ALTER TABLE notice ADD CONSTRAINT unique_board UNIQUE (board_id);
🔚 종합 평가
항목 | 점수 | 평가 |
정규화 | ⭐⭐⭐⭐⭐ | 완벽 |
관계 설계 | ⭐⭐⭐⭐☆ | 명확하나 일부 제약 없음 (공지사항 1:1 등) |
성능 최적화 | ⭐⭐⭐☆ | 인덱스 추가 필요 |
확장성/유지보수성 | ⭐⭐⭐⭐⭐ | 우수 |
전체 점수 | 4.5 / 5.0 | 실무급 좋은 설계지만 인덱싱, 일부 제약만 보완하면 완벽 |