[4주차] 외래키 제약 조건을 포기하는 이유

[wbluke]

(회사 스터디에서 이야기가 나와서 같은 이야기로 발제해 봅니다)

보통 개발 처음 배울때는 여러 테이블 간 외래 키 제약 조건을 거는 것이 좋다고 배우는데, 막상 실무에서는 외래 키 제약 조건을 전부 빼버리는 설계 방식이 널리 쓰이고 있음.

[제약 조건이 없어서 발생하는 문제 케이스 (실제 있는 문제..)]

• 핵심 데이터를 삭제하면 이를 참조하고 있는 다른 테이블에서, 이를 사용하는 애플리케이션 로직에서 (핸들링할 수 없는) 예외 생김
• 만약 이를 CDC 등으로 다른 팀 DB 등으로 복제하고 있었다면, 구천을 떠도는 유효성 없는 데이터들이 여러 데이터베이스에 퍼짐 (오염)

참조 무결성을 포기하면서까지 제약 조건을 걸지 않을 이유가 있을까?

그럼에도 외래 키 조건을 걸지 않는 이유를 저는 나름대로 결론을 내렸지만 제 답을 말하기 전에 같이 얘기해보면 좋을 것 같습니다. ㅎㅎ

[jiwooo-kim]

테이블 간의 의존성이 후에 데이터 이동이나 마이크로 서비스 할 때 비용으로 작용할 수 있어서 ?!

[myeongjae-kim]

At GitHub we do not use foreign keys, ever, anywhere.
github/gh-ost#331 (comment)

[harrisleesh]

명재쌤 ->
깃헙 : 성능상의 이슈, 샤딩 할때 이슈, online DDL 제약

[harrisleesh]

우빈쌤 -> 참조 무결성을 지키는것 vs 성능 & 데이터 정합성 [winnner]
애플리케이션에서 참조 무결성은 잘 해결할 수 있다.
soft delete하면 사실상 참조는 가능?
테이블 마이그레이션, 온라인 DDL 등의 제약이 많이 된다.