RDB라고 해서 FK가 꼭 필요할까?

퇴사를 하면서 Off-Boarding 당시 받은 백엔드 피드백들이 있다

오늘은 그 중 하나인 외래키에 대해서 작성해보려고 한다

 

나는 그 당시 1인 백엔드 - 코틀린 스프링부트 개발자로 스키마설계까지도 참여를 했었다

간단한 프로젝트였기때문에 테이블은 10개정도 나왔었다

그 중 현실화를 하면서 모델링거쳐 1:N 이런 관계가 들어간다면 당연하게도 외래키도 있는 형태로 설계를 했었다

 

단순히 "A가 만들어지기 위해서는 B도 존재해야 한다"는 건 진리일 수 있다

"Order(주문)이 만들어지기 위해서는 User(사용자)가 필요하다"는 사실이다

로그인한 유저가 없으면 주문을 할 수 없는 것은 당연하기 때문..

 

그러면 수 많은 기업들이 정말 외래키를 사용하고 있을까? 확답은 못하겠지만 No쪽에 가깝지 않을까 싶다

소위 네카라쿠배라 불리는 대기업에 재직하고 있는 몇몇 지인이 있는데 그들의 답변도 외래키를 사용하지는 않는다고 했다

대신 어플리케이션 레벨에서 잘~ 하면 돼 라고 했다

 

왜 다수의 기업들에서 외래키를 사용하지 않는지, 퇴사를 하면서 받은 피드백에서 왜 모든 연관테이블에 외래키를 걸으셨는지?에 대한 질문에 그때 답을 못했던 걸 지금 회고하고 발전시켜보려고 한다

 

외래키를 왜 거는걸까?

장점

• 데이터 무결성 보장
• 자동 참조 무결성 관리(CASCADE)
• 객체 그래프 탐색

단점

• 성능 저하
• 확장 어려움
• 유연성 부족

 

Then, 외래키를 왜 걸지 않는걸까?

장점

• 성능 최적화(INSERT, UPDATE, DELETE 연산에서 외래키를 검사하지 않음)
• 유연한 데이터 모델링
• 확장 편이성
• 단순화된 테이블 구조

단점

• 데이터 무결성 문제
• 쿼리 복잡성 증가(쿼리 최적화에 더 많은 노력이 필요)
• N+1문제
• 데이터 정합성 검증의 어려움

 

약간은 철 지난 주제이긴 하다ㅋㅋ;; 약간의 토론들도 있었고, 각자 회사마다 처한 상황이 다르기때문에 다른 답변들이 나올 수 있다

추가로 나는 이전 회사가 헬스케어 도메인이었다

Vital 데이터를 AI 모델에 넘겨줘야하는데, Vital에는 Patient(환자), 병동(Ward), 부서(Depart)가 외래키로 연관관계를 맺고 있었다

ML팀에서의 주요 관심사는 사실 병동, 부서정보는 딱히 필요 없고 환자와 생체데이터만 필요로 한 상황이었다

조금 시간이 지나서 기억이 확실하지는 않지만, 이 외래키의 제약이 꽤나 귀찮았던 기억이 있다

 

음.. 떠오르는 기억으로 아직 서비스를 나가지 않은 상황이고 내부적으로 특정 엔티티에 대해서 테스트를 해야하는데, 애플리케이션이 뜬 다음 이벤트로 받아서 초기 데이터를 넣는 과정에서 특정 엔티티를 테스트하기 위해서 관련없는 몇개의 더미를 리스트, 리스트..로 만들어야 했던 기억이 있다

 

아! 기억났다. 모델학습과정에 Vital 테이블이 필요하다고 하여, Vital_Temp로 떼어갈테니 스키마를 달라고 했다. 나는 당연히 인텔리제이로 Vital 테이블의 스키마를 생각없이 드렸는데... 왜 굳이 외래키를 걸었고, 그걸 같이 주냐면서 한번 생각해볼 필요가 있다고 말씀을 주셨다

 

크지 않은 회사였기 때문에 외래키를 걸어도 문제가 없었지만, 확실히 여러팀하고 작업해야하고 DB의 수평확장 등 추후 조작을 위해서는 백엔드 개발자가 손 가는 일이 더 많더라도, 외래키를 빼는 방향이 좀 더 유연한 것 같다

 

어쨌든!! 외래키를 걸었을 때의 장/단점, 외래키를 걸지 않았을 때의 장/단점에 대해, 다음 포스팅에서 코드로 직접 알아볼 예정이다