데이터 무결성을 유지하는 것 또한 무지 중요합니다..

그런 면에서 fk를 잡아주는 것이 좋겠죠..

그럼..

1초에 100-10000만원 씩 거래가 일어나는데

트랜잭션이 꼭 필요한가요?

?? 비슷하진 않지만...^^;

Fk와 인덱스가 꼭 필요한가에 대한 것은 정말 답을 하기 힘듭니다.

그러나 여러 DBMS가 가지고 있는 특징을 고려하고

또한 작업의 환경등을 고려했을 때

이쪽 업에 종사하는 사람들은

performance, 무결성을 고려치 않을 수 없습니다.

그 둘이 반드시 필요하냐를 답하기 전에

나는 스스로 자료의 무결과 performance를 보장할 수 있다라고 하신다면

구지 그 둘이 필요할까요?

그런데 Dbms를 사용한다는 것은 그것이 가지고 있는 특장점을 최대한

살려줘야 하지 않겠습니까?

의문점에 바탕해서 다시 답변글을 달아봅니다..

의문점 : FK의 생성에 따른 장/단점

고려사항 : Performance(성능) / Implementation(구현) / Management(관리)

기본가정 : FK를 생성하지 않을 경우, Application 등에서 제어함

<FK의 생성에 따른 장점>

1. RDBMS의 사용개념에 바탕한 효율적인 테이블 간의 Relation 설계를 바탕으로 각 Relation의 관계를 읽기 쉽다. 즉, 다시말해서 테이블의 추가, 삭제, 변경 등에 따른 DB구조의 관리가 용이하다. (물론, FK 유지를 위한 작업량은 조금 많아 질 수 있을 지 모르지만..) (관리 측면)

2. FK로 참조되는 테이블은 대개 대형테이블이 아니며, Join 등에 따른 실행시 부담이 적다. 대개 query를 잘못 작성해서 Perfomance의 문제가 발생하기도 한다. 즉, FK를 잡아주지 않고, Index만을 가지는 경우와 비교해서 특별히 Performance의 차이를 보일정도는 아니라고 생각한다. (개인적으로..) (성능 측면)

3. 1.에서와 같이 테이블 설계가 이루어진다면, FK의 구현은 별것 없다. 기존 시스템에서 FK를 구현할 경우, 각 테이블의 Data 무결 상황, Query의 검토 등이 이루어져야 할 것이다. (구현 측면)

<FK의 생성에 따른 단점>

1. 제약에 따른 Resource의 사용(trigger, check 등에 비해 현저히 적음)

2. 고려해야 할 항목이 늘어났음.. -_-;; 코드의 변경 등의 경우, FK의 참조순서를 고려해서 변경을 실행해야 함. (근데, 이건 단점이라기 보다는 무결성을 유지해 나갈 수 있다는 점에서 장점일 수 있겠네요. 코드를 아무렇게 변경해도 된다면, 변경 이전 데이터에 대한 데이터 무결성이 무너지는 순간이 되겠죠..)

3. DB 설계가 중요해짐. DB 뿐만 아니고 뭐든지 설계가 가장 중요합니다.

결론 속도면이나 구현면을 고려할 때, FK를 생성하는 것과 Index만을 생성해서 app등에서 데이터 무결성을 유지하는 것과 비교한다면, FK를 생성하는 것이 유리하다고 생각합니다. 물론 관리측면에서도 FK를 유지하는 것이 좋습니다.

즉, RDBMS를 사용한다면, Relation관계를 가지는 DB 설계가 기본이며, FK를 설정한다고 해서 Performance 등에 영향을 줄 정도는 아니라고 생각합니다.

그럼..

현문우답일지 모르겠는데요.

길가는 나그네님의 답변을 보고 참조키에 대한 고민을 다시 해보게 되네요.

Fk로 설정할 수 있는 것은 다른 테이블(참조하는테이블)의 PK이거나

또는 Unique 제약이 설정된 칼럼일때 가능합니다.

Fk로 설정된다고 하더라도 자동적으로 index가 만들어지는 것은 아닙니다.

또한 Fk로 설정하게 되면 참조당하는 칼럼의 삭제 및 변경을 할 수 없습니다. (이런 점에서 제약:Constraint 이라고 부르는 말이 나오지 않았나싶네요)

참조당하는 칼럼을 지우기 위해서는 Fk를 지운후에야 가능한 일입니다.

그냥 원론적인 이야기라도 해줘야 하지 않을까 싶어 주절주절했습니다.

rdbms 의 r 이 뭘까요?

그럼 이거 그냥 파일 디비로 쓰는게 낮지 않을까요?

속도도 빠르고

무결성은 다른 어플리케이션에서 구축하고

이런 이유에서 반드시 필요하다고 생각합니다.

그리고 참 짜증나는 경우는 다른 테이블에서 참조 당할때

유연하게 고치지 못하는 (EM 에서는 비교적 자유롭지만)

사용자를 피곤하게 하더군요

꼭 필요하다고 생각합니다. 인덱스로 대신 처리를 한다......

키로 잡힌 테이블은 인덱스를 잡아 주는 것이 좋습니다.

그래야 가들 끼리 빨리 빨리 찾죠 ^^;

인덱스로 대신 처리 한다는 말은 맞지 않은듯 하네요

또 후자가 와서 다이어그램을 그렸는데 1자로 쭉 나오겠죠 자기야

보면 알겠지만 후자는 아무도 모른다 볼려면 어플리케이션 다 보고

수정해야 한다는 불편도 따르죠

작으면 모를까 테이블이 많아지면 실로 심각한 문제 입니다.

경험해본 적 있을겁니다. 처음부터 끝까지 테이블이 일자로 서는거...

1. [테이블의 추가, 삭제, 변경 등에 따른 DB구조의 관리가 용이하다.]는 표현의 해석..

관계구조를 테이블에서 읽어낼 수 없다면, app에서 읽어내어야 합니다. 당연히 테이블(칼럼 포함)의 추가, 삭제, 변경의 경우, 시스템 전체를 훑어봐야 한다면 문제가 커지겠죠. 문제는 테이블 몇 개가 존재하는 시스템이 아니라는 것이겠죠.

2. [FK 대신 인덱스로 처리한다.]는 표현의 해석..

류풍산님의 의문점을 제대로 이해 했는지 모르겠지만, A 테이블의 a 칼럼이 B 테이블의 b 칼럼을 FK로 참조한다고 합시다. 그럼, B 테이블의 b 칼럼은 Index(PK 혹은 UK 모두 Unique라는 개념적 구현에 의해서)가 설정될 것입니다. 그리고, FK로 참조 제약을 걸어주게 되죠. 여기서 류풍산님께서 FK로 참조제약을 걸어주는 부분을 굳이 해 주지 않으면 좀 더 Performance의 향상이 기대되지 않을까라는 것으로 해석했습니다. 물론 A 테이블의 a 칼럼은 인덱스의 설정여부와는 관계 없습니다.

그럼..