Foreign Key: 논리적 vs 물리적

데이터베이스를 설계하다 보면, 테이블 간의 관계를 표현하기 위해 Foreign Key(외래키) 개념이 빠질 수 없습니다.
Foreign Key는 **참조 무결성(Referential Integrity)**을 보장해주는 중요한 장치이지만, 실무에서는 모든 경우에 물리적으로 설정하지는 않습니다.

 

논리적(Logical) Foreign Key

• 개념상으로는 다른 테이블을 참조해야 하는 컬럼
• 즉, 설계 상 "이 컬럼은 저 테이블의 PK를 바라본다"라는 논리적 관계만 성립한 상태
• DBMS 상에서 실제 제약조건을 걸어둔 것은 아님

 

물리적(Physical) Foreign Key

• DBMS 상에서 실제로 Foreign Key 제약조건을 설정해 두 테이블 간 참조 무결성을 보장하는 것
• 부모 데이터가 삭제·수정될 때 자식 테이블의 데이터도 영향을 받음
• ON UPDATE, ON DELETE 옵션으로 동작 방식까지 제어 가능

 

왜 항상 물리적 Foreign Key를 걸지 않을까?

성능 문제

• Foreign Key 제약조건이 있으면 INSERT, UPDATE 시 무결성 검사가 추가됨
• 트래픽이 많은 서비스에서는 성능 저하가 발생할 수 있음
• 이 경우 성능을 우선시하여 논리적으로만 FK 관계를 유지하기도 함

레거시 데이터(기존 데이터) 문제

• 이미 쌓여 있는 데이터가 참조 무결성을 깨고 있을 수 있음
• 이런 상황에서 FK를 강제로 걸면 제약 위반이 발생 → 서비스 운영 불가능
• 그래서 아예 물리적 FK를 걸지 않고, 무결성 체크는 별도 프로세스로 운영하기도 함

 

결론

• 논리적 Foreign Key: 개념적으로 참조 관계만 정의
• 물리적 Foreign Key: 실제 DB에서 제약조건으로 무결성 보장

실무에서는 성능과 레거시 데이터를 고려해 FK를 물리적으로 설정하지 않는 경우도 많습니다.
하지만 은행, 학사 관리 시스템처럼 100% 무결성이 중요한 서비스에서는 반드시 물리적 FK를 설정해야 합니다.