저번에 이와관련하여 여기에 자주 왕래하시는 고수분들이 토론을 하신적이 있습니다. 참조하시기 바랍니다.

1. 물론 부하를 주긴하는데... 생각보다는 정말 미미합니다.

아마 FK 컬럼에 Index를 만들지 않아서 발생하는 문제를 오인한 것 같네요. 막연히 부하를 준다고 하지 마시고 실재로 FK를 걸고 insert를 해보고 시간을 측정해보세요.

2. 트리거나 어플리케이션으로는 무결성을 지킬 수 없고, 지키도록 작성했더라도 FK를 거는것보다 훨씬 더 느립니다.

3. 대부분의 사이트가 FK를 걸지 않는데... 대부분 오해나 미신에서 비롯됩겁니다. 그들에게 얼마나 느려지는지 물어보십시오.

그리고 데이타가 무결성이 깨진 것들이 얼마나 많은지 한번 체크해보십시오. 절대로 제약조건을 거는게 쓸 데 없는 짓이 아닙니다.

한번 다음과 같은 경우를 상상을 해보세요. 고객 테이블에 없는 고객임에도 주문 테이블에 주문이 들어왔습니다. 분명히 이건 무결성이 깨진겁니다. 배송을 하기 위해서 고객 테이블을 뒤져서 주소나 연락처를 알아야하는데 위의 경우 불가능하겠죠. 결국 유령 고객이 되버리는겁니다.

또 제품 테이블에는 이미 삭제된 품목인데 주문 테이블에 고객이 주문한 내용이 들어있습니다. 무결성이 깨진거죠. 존재하지도 않는 상품을 배송하라는 항의가 들어올겁니다.

물론 업무적으로 어느 정도 오차가 있어도 허용이 가능하다면 굳이 걸어서 추가적인 오버헤드를 줄 필요는 없습니다. 이건 업무적으로 풀어야겠지요.

fk가 과도하게 걸려있는 경우 delete에 대해서는 심각한 성능 문제가

발생할 수도 있다고 보여집니다.

예를 들어서..

물품의 정보들이 저장되어있는 물품코드마스터 테이블이 있고..

해당 물품들의 판매내역, 보급 내역, 발주내역, 소요내역...등등..

물품코드마스터에서 물품코드를 fk걸어서 사용하는 테이블들이 많이

있고, 그 테이블에 무진장 많은 내역들이 저장 되어있을 때..

물품코드 마스터에서는 물품을 삭제하기 힘들 것입니다. 삭제할 때, fk가

걸려있는 모든 테이블을 확인해서 무결성문제가 없는지 판단을 하기 때문입니다.

물론 이런경우는 해당 레코드를 직접 삭제하지는 않고, 사용유무를

플래그를 통해서 관리하는게 보통이겠지만요.

그냥 이런 경우도 있을수 있습니다~

위에 분이 지적하신게 바로 FK 컬럼에 index가 없을 경우 죽음으로가는 케이스입니다.

보통 PK는 잘 변하지 않습니다. 허나 모델링을 잘못하여 자주 변하도록 하였다면... PK를 update할 때마다... Child 테이블에서 참조하는 것들이 없는지 매번 무결성을 체크하여야 합니다.

다행히 Child쪽에 FK컬럼에 색인이 있다면 잠금 없이 이 작업은 순식간에 끝납니다. (index scan이므로)

그러나 색인이 없다면... 오라클은 Child 테이블에 전체 잠금을 걸고 PK의 변경을 시도하므로 엄청난 성능 저하와 문제점이 발생합니다.

위와 같은 상황을 피하기 위해서는...

1. FK 컬럼에 반드시 index를 만들어주어라... 이 인덱스는 Nested loop조인등에서도 사용되므로 절대 쓸모 없는 짓이 아니다.

2. Master의 PK가 자주 변하도록 디자인하지마라.

3. PK를 Sequence등을 사용하여 artificial uid를 사용하라. 시퀀스는 인위적인 숫자이므로 자체적으로 의미를 가지지 않는다 따라서 업무 변화에 따라서 변경될 우려가 없다.

FK를 건 테이블과 걸지 않은 테이블에 각각 37만건을 insert하여 성능을 측정해봤습니다.

FK를 건 테이블은 25.12초가 걸렸고, 걸지 않은 경우는 22.68초가 걸렸습니다.

FK를 안걸어서 얻은 이득은 37만건 insert하는데 2.44초를 더 아꼈을 뿐입니다.

성의있는 답변 감사합니다. 제게 큰 도움이 되었습니다. ^^