FK (외래키)에 대해서 끄적끄적...

요즘도 많지만 SI에 외주를 맡겨 만들어진 서비스를 보면, FK가 걸려 있지 않은 것을 볼 수 있다.

많은 회사를 겪지 않은 2년 차 개발자이지만, 두 곳에서 다 동일한 현상을 볼 수 있었다.

두 번째 회사로 이직하기 전, 첫 번째 회사에서의 경험과 인프런에서 JPA를 다루는 많은 강의와 블로그들을 통해 FK를 거는 것이 당연하고 이렇게 해야 개발자가 편하고 유지보수하기 좋아! 라고 생각했다.

 

다른 글에도 있지만, 제미니의 개발실무 채널에서 다룬 영상을 보고 과거를 다시 생각해보기도 했다.

FK를 걸지 않았을 때, 분명한 장점도 있다.

SI에서 좋지 못하게 만든 예시에 너무 절여저서 그랬던 거 같기도 하다.

예를 들면, nullable한 FK 컬럼에 0을 기본 값으로 설정하는 부분이 있다.

생각해보면 요즘 null을 다루는 부분을 중요시하게 생각하는데, 예전에는 그런 관점이 좀 안 중요해서 그러지 않았을까라는 추측을 해보기도 한다.

 

그런데, 다시 생각해보면 내가 코드를 올바르게 짜 둔다면 FK를 무조건 항상 설정할 필요는 없다.

FK는 제약이다. 테이블을 선언할 때, constraint 라고 명시한다.

일상에서도 알 수 있듯이, 제약은 장점과 단점이 공존한다.

 

결혼, 연애, 집, 물건 구매 등 다양한 예시를 들 수 있겠지만, 집 계약을 예시로 들어보겠다.

집을 계약하려는데, 국가나 은행에서 지원하는 어떤 상품이 있다고 가정을 해보자.

이것을 가입하고 집을 계약하면, 계약자에게 꽤 이득이 될 만한 장점이 있다.

다만, 몇 년 이내에 집을 판다면 어떠한 손해가 발생할 수 있으니 알아둬야 하는 단점도 있다.

여기서 이 계약의 좋고 나쁨을 평가할 수 있을까?

내 생각은 계약자가 누구인지에 따라 다르다는 것이다.

 

테이블 간 FK 설정도 그렇다고 생각한다.

사이드 프로젝트를 하거나 업무적으로 새로운 프로젝트를 시작해야 할 때, 개발 환경을 고려해서 결정하면 된다고 생각한다.

뭐 프로젝트의 도메인, 개발자 인원 등등 많은 조건이 있을 것이다.

 

아무튼, 나의 요즘 생각은 굳이 FK를 걸 필요는 없다라는 것이다.

실력을 쌓고 더 좋고 빡센 회사에 들어가긴 힘들겠지만, 그곳에서의 경험을 했을 땐 또 생각이 달라질 수도 있을 건데,,,

그 때가 있다라면, 어떻게 생각을 하고 있을 지 궁금하다.