작성한 질문수 16

1

jjs270402님, 안녕하세요!

실무에서 외래키 제약 조건은 걸지 않는게 일반적입니다.

물리적인 제약 조건을 걸면 스키마 변경에도 어려움이 생기고, 데이터 CUD 시에도 제약 조건을 검증해야 하므로 DB 부하는 더욱 커집니다.

DB의 리소스는 가장 소중하게 다뤄야할 부분이고요. (결국 모든 병목/장애 지점이 DB가 될 수 있으므로)

그렇기 때문에 물리적인 제약 조건은 걸지 않습니다.

댓글 테이블은 논외로 보고 애초에 테이블 자체가 물리적으로 분산되어 있는 분산 DB라면, 물리적 제약 조건을 아예 설정하지 못할 수도 있습니다.

그렇다고 외래키가 아예 없다는 의미는 아닙니다.

논리적인 설계에서는 외래키를 설정한 것이 맞고, 물리적인 제약을 설정하지 않는다는 의미입니다.

그리고 논리적인 관계에 대해서는 DB 제약 조건으로 검증하는게 아니라, 애플리케이션에서 직접 제약 조건을 검증할 수 있는 것이고요.

강의에서도 이러한 방식을 취하고 있습니다!

0

안녕하세요, 인프런 AI 인턴입니다. jjs270402님.

댓글 테이블의 설계와 외래 키 제약조건에 대한 질문을 주셨군요. 이는 데이터베이스 설계에서 중요한 부분으로, 선택하는 데 있어서 다양한 고려사항이 있습니다.

외래 키 제약조건을 생략하는 이유

1. 성능 최적화:

   • 외래 키 제약조건은 데이터베이스가 관계를 유지하기 위한 추가적인 부담을 줍니다. 특히, 대량의 데이터 삽입 및 업데이트가 발생하는 환경에서는 이로 인한 성능 저하가 발생할 수 있습니다.
     

2. 유연한 스키마 변경:

   • 외래 키 제약조건이 걸려 있을 경우, 스키마 변경 상황에서 더 복잡한 절차가 필요하며 유연성을 저해할 수 있습니다.
     

3. 독립적인 애플리케이션:

   • 마이크로서비스 아키텍처를 적용하는 경우, 각 서비스가 독립적인 데이터베이스를 사용할 수 있습니다. 이런 경우 데이터베이스 간 강한 결합을 방지하기 위해 외래 키를 사용하지 않기도 합니다.
     

4. 애플리케이션 레벨에서의 데이터 무결성 관리:

   • 데이터의 일관성과 무결성은 애플리케이션 로직으로 관리할 수 있으며, 트랜잭션이나 ORM의 관리 하에 관계를 처리합니다.
     

이와 같은 이유들로 인해 외래 키 제약조건을 제외하는 선택을 할 수 있습니다. 기존의 관련된 토론 및 설명을 찾는데 도움이 될 수 있는 게시물은 아래와 같습니다:

• 테이블을 생성할 때 관계 명시를 안 하는 게 더 나은지 질문드립니다! (게시글 제목)
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.