kiworkshop / designing-data-intensive-applications

0 stars 0 forks source link

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

Open wbluke opened 11 months ago

wbluke commented 11 months ago

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

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

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

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

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

jiwooo-kim commented 11 months ago

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

myeongjae-kim commented 11 months ago

At GitHub we do not use foreign keys, ever, anywhere. https://github.com/github/gh-ost/issues/331#issuecomment-266027731

harrisleesh commented 11 months ago

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

harrisleesh commented 11 months ago

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