FK의 옵션에 따라서 다르게 반영됩니다.

물론 마스터테이블이 변경될때, FK테이블이 같이 변경되게 세팅된다면 그런 현상이 발생할수 있습니다.

그렇지 않게 세팅할수도 있습니다.

다만, FK를 걸어서 얻게되는 이익이 그리 크지 않습니다. 구지 거셔야한다면 꼭걸어야 하겠지만, DBA의 말대로 데이터일관성 측면에서는 FK보다는 프로그램으로 처리하는 경향이 많습니다.

또한, FK가 조인의 성능에 미치는 영향이 미미하기 때문에 실제로 FK를 걸어서 얻는이익은 그것을 생성해서 발생하는 cost보다 많지 않습니다.

참고만하세요,

글 읽고 저도 한가지 궁금한게 있어서 한자 적습니다.

부모테이블이 변경될 경우 자식테이블에 Full Lock이 걸린다고 하셨는데, 자식테이블의 FK에 대응(?)되는 부모테이블의 PK가 아닌 다른 컬럼이 수정되어도 자식테이블에 Full Lock이 걸리는 것인가요?

그렇지 않다면... 보통 PK가 수정될 경우는 거의 없고, 수정이 필요한 경우에라도 추가로 insert를 해야지 update를 해서는 안된다고 알고 있습니다. 이렇다면, FK를 걸어서 성능상에 큰 이익을 보는 것이 아니더라도 모델링 측면에서 봤을 때는 FK를 생성하는 것이 맞는게 아닌지요.

모델링 공부한지 얼마 안대서 어리버리 합니다^^;

틀린부분있으면 과감한 지적 부탁합니다.

PK 와 FK 의 경우 윗 분이 말씀하신데로... 데이터 베이스 모델링 측면에서 아주 중요한 부분이 됩니다.

즉 데이터의 일관성 유지및 스키마 관계에 대한 해석 및 정규화 등의 문제로 볼때 아주 중요한 설정이 될껍니다.

COST 비용을 말씀하셨는데... 만약 관리 하는 테이블이 정말 많다면.. 이 부분을 어떻게 일일이 다 프로그램으로 처리를 하여 관리하시겠다는 말씀인지... 관리가 가능할까요? 정말 중요한 데이터 들이라면...

PK 및 FK 설정시 말씀하신데로 LOCK 이 걸리는 현상은 발생합니다.

즉 SX 타입의 LOCK 이 걸려서 enqueue wait 이 발생하기도 합니다.

권장 사항은 fk 컬럼에도 인덱스를 생성하는 것입니다. 즉 대부분의 경우 pk 와 fk 간의 join 이 많이 발생하며, 조인시 update나 기타 insert 시 검색시간이 많이 걸린다면, 즉 해당 키를 찾기 위한 시간이 많이 걸린 다면 그만큼 테이블에 lock 이 오랜동안 지속되어 dead lock 이 발생할 확률이 많다는 이야기죠... 이런 부분들을 위해서 가능한한 fk 에 index 를 생성해 줄 것을 권고 하고 있으며, update 나 기타 insert 가 많이 발생하는 테이블이라면 initrans 나 freellists 를 더 늘려서 원활한 처리가 이루어 질수 있도록 하는 것도 방법이 될거 같습니다.

^^;; 수고하세요...

FK인 컬럼에 색인을 만들지 않았을 때 잠금 문제라든가. 데드락 상황이 생길 수 있음은 나그네님이 잘 설명해주신 것 같습니다.

저는 다른 관점에서 이 문제를 언급해보고자 합니다.

왜 현업에서 Foreign Key를 사용을 꺼리는걸까요?

첫째, 위와 같이 FK컬럼에 색인을 만들지 않았을 때 발생하는 부정적인 영향을 들을 경험한 DBA나 개발자는 FK를 이론적으로나 가능하고 실재론 못쓸 물건이라는 결론을 내리기 때문입니다. 허나 색인을 만들어주고 사용하면 됩니다.

두번째, FK가 성능에 악영향을 준다는 믿음. 매번 자식 테이블에 row를 insert할 때 마다 부모-자식 관계를 검증하기 위해 오버헤드를 준다는 믿음.     물론 FK를 주면 오버헤드가 있습니다. 하지만 테스트 결과 우려할 만큼 심각한 영향을 주는건 아니었습니다. 오히려 FK를 사용하지 않음으로써 불필요한 Outer join의 남발로 인한 성능 문제가 더 심각한게 현실입니다. 그러니 꼭 필요하다면 FK를 거십시오.

자료의 무결성은 그 무엇보다도 중요합니다. 나중에 정합성이 맞지 않는 쓰레기 데이타를 가지느니 FK를 걸고 두 다리 쭉 뻣고 주무시는게 훨씬 유익합니다.

그러나 로그성 테이블 처럼 무결성이 크게 중요치 않은 경우 걸지 않아도 됩니다.

세번째, 자료의 무결성 체크를 DB가 아닌 클라이언트에서 3GL언어를 사용해서 하려는 경향...

왜 이런 잘못된 믿음이 생겼는지는 모르나 대부분 DB의 잠금이나 무결성에 관련된 메카니즘을 잘못 이해함으로 생기는 미신입니다.

예를 들어... 어차피 이 자료는 VB로 만든 콤보박스에서 선택하도록 강제되므로 FK나 제약조건(Constraints) 가 불필요하다는 믿음.

이건 동시성 문제를 전혀 생각하고 있지 않다는 이야기가 됩니다.

무결성 체크를 어플리케이션에서 하기 위해서 자식 테이블에 insert를 하기 전에 부모키의 존재 여부를 확인하도록 루틴을 추가했다고 칩시다.

select count(*) into v_cnt from parent_table where key=123

v_cnt가 1이상이면 부모가 존재하므로 자식 쪽에 insert하는 것을 허용하도록 코드를 했습니다.

위에서 간과한 것이 count 직후 만약 부모 테이블의 자료를 삭제한다면 정상적으로 작동하지 않습니다.

결국 동시성 문제를 이해한 개발자라면 for update 로 잠금을 걸던가 해야 정확합니다.

허나 이리하면 실재로 FK를 건것보다 더 성능이 나오지 않습니다. 게다가 어플리케이션에 불필요한 코드가 들어감으로써 성능이 더 악화됩니다.

결론 데이타 정합성이 조금이라도 중요한 테이블이라면 FK를 반드시 거십시오. 그리고 불필요한 outer join을 남발하거나 3GL언어에서 정합성을 체크하려는 복잡성과 오버헤드를 제거하십시오.

이는 "제약조건을 사용하지마라"라는 미신과 더불어 정말 오래된 미신 가운데 하나입니다.

오우... 이해가 팍팍되는... 답변들이십니다...s-_-b

또 배워갑니다.. 감사^^/

좋은 글들 감사합니다. 그러나, 아직도 현실적으로 FK를 사용하는데는 문제점이 있습니다. 개발자였으며 현재 DBA 쪽에 가까운 사람입니다.

이런적으로나 데이터 정합성 측면에서 FK는 확실한 대안일수 있습니다.  만약 4GL 같은 툴을 사용하지 않고 DB만으로 모든것을 처리한다면 FK는 확실한 효과를 거둘수 있는 대안이고, 관리 작업의 비용도 줄어들게 됩니다.

그러나, 현실에선 DBA의 role과 개발자의 role이 엄현이 구분됩니다. DBA는 데이터베이스의 모든권한을 가지고 있지만 개발자는 최소한의 권한만을 가지고 작업을 하는게 현실입니다. 이는 개발자가 DB의 생성권한도 없으며, 생성된 DB의 개별 개체의 형태를 조회할수 없을수도 있다는 이야기입니다. 이런상황에서 FK등의 제약사항을 가지고 있다면 개발자는 FK에 반한 작업을 할수도 있습니다.

또한, 어플리케이션의 입장에서 볼수도 있습니다. 한회사에 고객DB와 물건 판매기록이 있습니다. A라는 사람이 대리점에서 물건을 구매했습니다. 그럼 구매즉시 전표를 입력할것입니다. 그런데 공교롭게도 그는 그회사의 고객명부에 없습니다. 어떻게 할까요, 고객한테 회원이 아니니 회원가입양식을 입력하셔야만 물건구매를 할수있습니다. 이럴까요? 일단 구매기록을 입력하고, 고객등록을 받는게 고객우선 주의겠지요?

위와 같은 문제점은 FK를 사용할때 나타나는 문제들의 극히 일부입니다. FK는 이론상으로 또는 DB관리상의 비용을 상당히 줄여주는것은 사실입니다만, 현실에는 여러가지 예외사항이 있습니다. 물론 이건 FK만의 문제가 아니라. 이론을 실제에 적용할때 발상하는 문제들입니다.

꼭 FK를 사용할것이다,(혹은 프로그램적으로 제약사항을 걸것이다) 이런건 신중한 고려가 필요합니다.

입시프로그램을 짠적이 있습니다. 국내에는 주민번호알고리즘에 위배되는 주민번호도 상당수가 있습니다. 제약사항으로 주민번호 알고리즘을 체크했다면, 그사람은 대학입시 기회조차도 없었겠지요,

이론을 무시하자는 이야기는 아닙니다. 이론을 알아야하는것은 확실하지만 현실에 반영하는문제는 신중을 기해야 합니다,

좋은지적글들 감사합니다.^^

장종훈님의 말씀도 맞지요. 업무상 그렇다면 재고해봐야할 겁니다.

제가 FK를 이야기하는 이유 중에 하나는 또 이런게 있습니다.

A라는 회사가 있습니다. VB 로 C/S방식의 어플리케이션을 작성해서 내부용으로 사용하던 것을 이젠 웹으로도 제공하기로 결정이 되었습니다. 그러니까... VB와 웹 모두 서비스를 제공해야 합니다.

만약 제약조건과 FK등을 사용했다면 데이타베이스의 무결성은 데이타베이스 자체가 검증하게 됩니다. 그러나 만약 그 동안 VB에서 3GL코드로써 이러한 작업을 해왔다면... 웹에서도 동일하게 이러한 에러 검증 코드를 재작성해야합니다. 그리고 어떤 이유로 에러 검증 루틴이나 규칙이 변했다면 VB로 작성한 코드와 웹코드를 모두 고쳐주어야 합니다.

만약 두개의 에러검증 코드가 일치하지 않는다면 데이타 무결성에 문제가 발생하게 됩니다.

자! 이 경우 DB에 이들 제약조건과 FK를 거는게 더 시간을 줄여줄까요? 아니면 3GL 코드에 이걸 박는게 더 좋은걸까요?

그 dba 에게 thomas kyte 가 쓴 effective oracle 의 1 장을 읽어보라고 하세요.(번역본도 있더군요)

"데이터베이스는 데이터더미가 아닙니다."

 fk 다시고, 윗분 고수님들 말씀대로 fk 에 대해 인덱스 생성하세요.

대용량인가 아닌가는 기준이 될 수가 없습니다.

대용량이어서 FK나 Constraints를 쓸 수 없다는 이야기는 대용량이면 데이타 무결성이 깨어져도 상관없다는 이야기가 될 수도 있습니다.

좀 극단적으로 논의를 확장하면 대용량이면 Join도 쓰지 말아야한다는 논리까지 갈 수 있습니다. (실재로 이런 경우 있습니다.)

결론은 데이타 무결성이 기준이 되어야지 대용량 여부는 상관이 없습니다. 정규화 잘하고 Constraints걸고, FK 걸고도 성능 제대로 내는 것 얼마든지 가능합니다.

저는 장종훈님의 의견에 동갑합니다. 

아무리 설계상 FK 의 설정을 완벽하게 했다고 해도 업무를 하다보면 우리의 친애하는 현업님께서 

예외사항을 들고 오십니다. (^^ 다들 이부분에서는 공감하실 듯)

그러면, 저는 무조건 안 된다고 하죠. 그렇게 처리하는게 아니라고 ...그러면 현업도 알고 있다고 하면서

윗분들 예기 꺼네죠.(사장님 이하~~~ 쭉) 꼭 해야 되는 급한거라고( 어쩔수 없죠. 현업이 갑이니. ㅠ.ㅠ)

그렇다고 FK 를 없앨 수는 없는 거 아닙니까. 그러면 부모테이블과 자식테이블에 가상의 데이타를 입력하게 되는 경우가 생기죠...

이런것들이 하나둘 쌓이다 보면, FK의 본질적이 의미가 많이 퇴색되게 됩니다. (시스템 개발후 장시간이 흘렀으면 더 말할 것도 없구요)

윗분들 예기처럼 FK 는 성능상의 큰 차이점은 없는 거 같습니다. 

그런데, 제가 하고 싶은 예기는 이론과 현실은 다소 차이점이 있다는 것입니다. 

훌륭하신 분들의 좋은 글에 몇자 적었습니다.