[DBA] foreign key(외래키) 단점과 위험성에 대해

foreign key (외래키)

---

1. 관계를 맺고있는 릴레이션 R1, R2 가 있을 때 R1이 참조하고 있는 릴레이션 R2의 기본키와 같은 R1 릴레이션의 속성을 말합니다.

2. 외래키는 참조되는 릴레이션의 기본키와 참조관계를 맺는데 중요한 Key 입니다.

말이 어려울 수 있으니 간단하게 테이블로 참조해보도록 하겠습니다.

  Blogs 테이블에는 BlogID 의 기본키가 있습니다.

  Posts 테이블에는 BlogID 를 외래키로 참조하여 구성하였습니다.

  즉, 하나의 Blogs 에는 여러개의 Posts 를 구성할 수 있다는 관계를 나타내고 있습니다.

  

이처럼 DB 에서 설계, 관계도는 매우 중요합니다.

그럼에도 많은 사이트에서 foreign key 를 사용하지 않는 경우가 많습니다.

foreign key 를 왜 사용하지 않을까

---

1. 관리의 비용 문제

부모 테이블의 구조를 변경해야 하는 경우 자식테이블의 구조에 이상이 없을지 다 확인해야 합니다.

2. 실행계획을 제어할 수 없음

DBA 라면 DB 를 제어할 수 있어야 하고 즉, 실행계획을 제어할 수 있어야 합니다.

실행계획을 제어하고 쿼리가 언제 끝나는지, 수행하면서 이슈는 없는지에 대해 파악할 수 있어야 합니다.

위 구조로 예를 들어보겠습니다.

Blogs 테이블에 BlogID 가 10,000 인 데이터를 삭제해본다고 가정합니다.

각 테이블의 전체건수와 삭제건수는 아래 표와 같습니다.

테이블	전체건수	삭제건수
Blogs	132,434	1
Posts	74,239,113	55,291

'DELETE FROM Blogs WHERE BlogID = 10,000'  쿼리를 실행했을 때,

Posts 테이블의 데이터 삭제 시 Row Lock, Tab Lock 을 제어할 수 있을까요?

Posts 테이블의 데이터 삭제 시 Scan, Seek 의 실행계획을 강제할 수 있을까요?

위 쿼리가 언제 끝날지 알수 있을까요?

(대량 데이터 변경작업 시, 보통은 단위처리로 진행합니다. 이유는 생각해보셨으면 좋겠습니다.)

물론 자식테이블부터 지우면 되지 않을까요? 라고 질문주실수도 있습니다.

이런 경우라면 굳이 foreign key 를 만들지 않고 어플리케이션에서 잘 제어하도록 처음부터 설계를 진행하는게 이후 관리에서도 더욱 용이할 것입니다.

* 이 포스팅은 foreign key 의 위험성에 대해 다루었을 뿐 사용하면 안된다는 것은 아닙니다.

foreign key의 기능이 필요한 곳이 있기에 기능이 개발되었을 거고,

규모, 서비스 용도등 따라 foreign key 를 사용함으로써 좋은 경우도 있을거라고 봅니다.

사용함으로 써 얻는 이점과 단점에 대해 판단 후 결정하여 좋은 서비스를 운영하셨으면 좋겠습니다.