PK(Primary Key), FK(Foreign Key) 같은 제약 조건을 논리적으로만 정의하고 물리적으로는 생략하는 경우가 많아지고 있다. 특히 대규모 트래픽을 처리해야 하는 서비스나 마이크로서비스 아키텍처에서는 이런 방식이 성능과 유연성을 위해 선택되곤 한다.
🔍 왜 PK, FK를 생략할까?
- 성능 이슈
FK는 참조 무결성을 보장하기 위해 삽입, 수정, 삭제 시마다 추가적인 검증 작업이 필요해요. 이게 대량의 트랜잭션이 발생하는 시스템에서는 병목이 될 수 있습니다. - 개발 유연성
FK가 있으면 테이블 간의 삽입 순서나 삭제 순서가 제약을 받기 때문에, 개발이나 배포 시 복잡도가 올라갑니다. 특히 마이크로서비스에서는 각 서비스가 독립적으로 동작해야 하므로 FK를 피하는 경우가 많다. - 데드락 위험
FK로 인해 잠금(Lock)이 전파되면서 데드락이 발생할 가능성이 높아져요. 이를 피하기 위해 FK를 제거하는 전략을 쓰기도 합니다.
💡 그럼 PK도 생략하나?
PK는 일반적으로 인덱스와 무결성 보장을 위해 여전히 많이 사용된다. 다만, 복합 PK나 비효율적인 PK 순서로 인해 성능 저하가 발생할 수 있어서, PK를 인덱스 관점에서 재설계하거나 논리적으로만 정의하는 경우도 있습니다.
무결성 관리는 애플리케이션 레벨에서 처리합니다!
공부 정리 블로그