본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 15일차!
오늘은 커뮤니티 피드 서비스 프로젝트에 JPA를 이용한 게시글 및 댓 엔티티 작성 작업을 진행하였다.
게시글 엔티티를 작성하던 중, 연관관계를 설정해야 하는 상황이 생겼다.
@ManyToOne
@JoinColumn(name = "author_id", foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
private UserEntity author;
한 유저는 여러 개의 게시글을 작성할 수 있으니, UserEntity 타입의 author(게시글을 작성한 유저) 필드를 @ManyToOne 어노테이션을 통해 다대일 관계로 설정하였다.
그리고 @JoinColumn 어노테이션을 통해 데이터베이스 상에서 이 관계를 author_id라는 이름의 컬럼으로 매핑하였으며, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT) 설정을 통해 외래 키 제약 조건은 생성하지 않도록 하였다.
DDL 생성 시에 FK 생성 제한을 걸지 않으면 생기는 단점이 있다. (물론 상황에 따라 FK가 필요하기도 하다)
- 원치 않는 인덱스가 걸린다.
- FK를 만들면 DB는 자동으로 참조 대상 컬럼에 인덱스를 생성하기 때문에, 그 인덱스가 저장 공간을 차지하고 INSERT/UPDATE 작업 시에 부하를 추가한다.
- 제약조건으로 인해 데이터 수정의 어려움이 증가한다.
- FK가 존재하면 DB는 참조 무결성을 보장하려고 하기 때문에 데이터 수정, 삭제 작업에 문제가 생길 수 있다.
기업체에서 실습생으로 일했던 당시, 기능 개발을 위해 새로 데이터베이스 테이블을 생성해야 했었다.
그동안 늘 외래키를 설정했기 때문에 이번에도 당연히 테이블에 FK를 추가하였는데, 사수님께서 외래키는 지우는 게 좋을 것 같다고 피드백을 주신 적이 있었다.
그때는 왜 FK를 만들지 않는 건지 잘 이해하지 못했는데 이번 강의를 보고 나니 인덱스가 굳이 필요하지 않은 작은 테이블(사내 CS 작업 히스토리용)이라는 특징을 고려하였을 때, FK를 만드는 것이 오히려 불필요한 제약을 만들고, 유지보수나 성능 측면에서도 이점이 없을 수 있다는 것을 알게 되었다.