GitHub에서는 어디에서도 외래 키를 사용하지 않습니다.
개인적으로, 외래 키가 좋은지 나쁜지 결정하는 데 꽤 오랜 시간이 걸렸으며, 지난 3년 동안 외래 키를 사용하지 않아야 한다는 강한 의견을 가지고 있습니다. 주요 이유는 다음과 같습니다:
•
FK는 데이터베이스를 샤드하는 데 방해가 됩니다. 앱은 외래 키를 의존하여 무결성을 유지하기 때문에 자체적으로 유지하지 않습니다. 심지어 FK를 cascade delete(끔찍한 일)하는 데도 의존할 수 있습니다.
데이터를 샤드하거나 추출하려면 앱을 알 수없는 범위로 변경하고 테스트해야 합니다.
•
FK는 성능에 영향을 미칩니다. 인덱스가 필요하기 때문에 필요한 인덱스는 아마도 괜찮을 것입니다. 그러나 각 insert/delete마다 수행하는 조회는 overhead입니다.
•
FK는 온라인 스키마 마이그레이션과 잘 작동하지 않습니다.
이 마지막 불릿은 생각하는 것처럼 닭과 달걀의 문제가 아닙니다. FK는 가능한 것과 불가능한 것에 많은 제약을 가합니다.
P와 C 두 개의 테이블이 있다고 가정해보겠습니다. 각 행이 P에서 어떤 "부모"값을 가리키는 C에 외래 키가 있습니다.
C의 스키마 마이그레이션은 가능합니다. 그러나 외래 키에는 고유한 이름이 있으므로 새로운(마이그레이션 된) C 테이블은 원래 이름과 다른 이름을 가진 FK를 갖게 됩니다.
P의 스키마 마이그레이션은 작동하지 않습니다. gh-ost는 테이블 이름을 마지막에 바꾸기 때문입니다. 테이블을 옮길 때 FK도 함께 이동합니다. ghost 테이블에서 부모 측 FK를 만들려면 C를 마이그레이션해야 합니다. 그리고 gh-ost는 async 접근 방식을 사용하기 때문에 P와 P-ghost는 잠금 시점을 제외하고 어느 시점에서도 완전히 동기화되지 않으므로 C가 P와 P-ghost에 모두 FK를 가질 수 없기 때문에 일부 무결성이 깨집니다.
pt-online-schema-change 문서에서 더 많은 토의가 있습니다.