FK 지정 시 주의해야 할 점

[jimi567]

연관 관계가 있는 테이블은 무조건 FK를 거는게 좋을까?

[le2sky]

외래키는 관계형 데이터베이스에서 한 테이블의 필드 중 다른 테이블의 행을 식별할 수 있는 키를 말합니다.
외래키 자체는 비정규화를 하지 않는 경우에는 항상 있는 것이 좋습니다.
외래키를 사용하면 중복 데이터를 줄일 수 있기 때문입니다.

질문의 핵심은 FOREIGN KEY 제약인 것 같습니다.
FK 제약을 준다면 외부 키가 존재해야하기 때문에 참조 무결성을 지킬 수 있습니다.
반면, 성능에 문제가 발생할 수 있으며 테스트 시 번거로울 수 있습니다.
또한 부모 테이블이나 자식 테이블에 데이터가 존재하는지 확인하는 작업이 필요하기 때문에
잠금이 전파될 수 있습니다. 그리고 이로 인해서 데드락이 발생할 수 있습니다.

실무에서는 FK 제약을 잘 사용하지 않는다는 이야기가 있는데요.
FK 제약을 제거하는 것이 드라마틱한 성능 최적화 포인트인지 모르겠고,
얼마나 불편한지 진하게 경험해보지는 않아서 와닿지는 않습니다.
개인적으로는 FK 제약을 설정하고, 필요한 경우에 제거를 고려해볼 것 같습니다.

[J-I-H-O]

답변하기가 애매한 것 같아 참조 무결성 제약조건으로 인해 테스트 시 번거로움을 느낀 경험을 첨부합니다.

@AfterEach
void cleanUp() {
    reservationRepository.deleteAll();
    reservationTimeRepository.deleteAll();
    themeRepository.deleteAll();
    memberRepository.deleteAll();
}

테스트 격리를 위해 각 테스트를 실행한 뒤에 DB 테이블을 초기화 해야하는 상황을 예로 들어보겠습니다.

Reservation 테이블이 ReservationTime, Theme, Member의 FK를 가지고 있고, 참조 무결성 제약조건 때문에 Reservation을 삭제해야만 각각의 테이블을 초기화할 수 있었습니다.
이때 삭제 순서를 지키지 않는다면 참조 무결성 제약조건으로 인한 예외가 발생합니다.
즉 반드시 Reservation을 먼저 삭제해야한다는, 삭제 순서를 인지해야 하는 비용이 있었습니다.

또 요구사항의 변경으로 새로운 테이블이 추가될 때마다 기존 테이블과 새롭게 추가된 테이블의 관계를 고려해 삭제 순서를 재배치해야 합니다.
이와 같은 경험을 통해 FK를 지정했을 때 테스트의 유지보수가 어려워짐을 느낄 수 있었습니다.

이 부분은 trade-off를 따져보고 결정해야 하는 부분인 것 같습니다.
다만, 무작정 FK를 거는 행위는 지양해야겠다고 생각했습니다.