'어느 회사에선 FK를 사용하지 않는다더라 아니다 어느 회사에선 사용한다더라..' 라는 이야기를 들으면서 어느 경우 FK를 사용하는게 적절하고 어느 경우 FK를 사용하지 않는게 적절한지에 대한 의문이 들어 공부했습니다.
FK는 한 테이블이 다른 테이블을 참조하는 제약 조건이라 데이터 무결성을 보장하여 안전한 데이터 관리가 가능하다. 그러나 성능 저하를 유발할수도 있고, 복잡도 때문에 데이터베이스 운영 난이도를 높일 수 있다.
FK를 사용하지 않는 경우보다 FK를 사용할 경우 데이터 변경 시 더 많은 lock을 유발하기 때문에 동시성이 높은 상황에서 성능 저하가 발생할 우려가 있다. 데이터 변경이 빈번한 경우 성능 저하에 대한 문제가 더 많이 발생할 수 있다.
FK를 사용하면 데이터 변경이나 삭제 시 관련된 각 테이블 간의 연관성을 고려해야 한다. 테이블의 수가 증가하고 관계가 더 복잡해질수록 데이터 수정 작업은 점점 어려워진다. 그리고 FK가 적용된 열에 데이터 타입 변경이 제한되거나 샤딩 등으로 여러 데이터베이스에 데이터가 분산될 때 유지 관리가 더 어렵다.
대신 FK를 사용하지 않는 경우, FK 제약 없이 참조 무결성을 유지할 수 있도록 시스템을 설계해야 한다.
주로 데이터 무결성이 중요한 은행이나 결제 도메인의 경우 FK를 사용한다. 그리고 데이터 변경이 빈번하지 않고 조회만 빈번할 경우에도 FK를 사용할 수 있습니다.
많은 테이블이 있고 그 테이블 간의 관계가 복잡한 대규모 서비스의 경우, FK를 사용하면 운영 난이도가 훨씬 복잡해지기 때문에 대규모 서비스는 FK 사용을 지양하고 있다.
그리고 데이터 삭제와 같은 데이터 처리가 있을때 파티셔닝 기능을 사용에 어느정도의 데이터 무결성 확보가 가능하다고 판단하면 FK를 사용하지 않는다.