PK와 FK

PK

• 테이블을 생성할 때 PK를 정의한다.
• PK는 각 행을 고유하게 식별해주는 컬럼이다.
• 테이블당 하나만 정의 가능하다.
• NOT NULL + UNIQUE KEY값을 가짐
• 고유 인덱스가 자동으로 생성된다.

여기서 테이블당 하나만 정의 하다는 것을 이해할 때 PK가 여러 컬럼으로 구성될 수 있지만, PK값은 하나인 것으로 이해해야 한다. 예를 들어, 상품의 거래내역 테이블에서 PK값으로 상품코드와 판매코드를 키값으로(PK) 설정해 ROW를 식별하는 것과 같다. 만약 상품코드만 잡게 되면 동일 상품에 대해서 식별할 수 없고, 판매코드로 잡으면 같은 영수증에 판매건에 대해 식별할 수 없으니 두 값의 CONCAT값으로 키값을 잡는 것!

 

FK

• 테이블을 생성할 때 FK를 정의한다.
• FK가 정의된 테이블이 자식 테이블이며, 참조되는 테이블이 부모 테이블이다.
• 부모 테이블의 참조되는 컬럼에 존재하는 값만을 입력 할 수 있다.
• 부모 테이블은 FK로 인해 삭제가 불가능하다.
• 데이터 타입이 일치해야 한다.
• 참조되는 컬럼은 PK이거나 Unique만 가능하다.

 

데이터 정합성 측면에서 FK는.. 꽤나 민감한 설정이라고 생각한다. 설계할 때야 굉장히 체계적으로 테이블간의 관계도를 짜놓지만, 미래에 어떤 테이블이 삭제 되고 추가될지 모르는데 FK를 마구 걸어놓으면 나중에 손대는게 아주아주 힘들어 질 것 같다. 결국 확장성을 고려해보면 민감해진다.

 

참고 : m.blog.naver.com/PostView.nhn?blogId=hist0134&logNo=220249120040&proxyReferer=https:%2F%2Fwww.google.co.kr%2F

 

그리고 현재 회사에서 FK를 설정하는 경우를 많이 보지 못했다. 생각해보면 유통 데이터, 특히 결제 데이터를 기반으로 한 상품 데이터에서 FK를 쓰기는 쉽지 않을 것 같다. 유통 데이터 같은 경우 고객정보 동의, 비동의도 수시로 바뀌는 판에, 디폴트가 ON DELETE인 FK를 설정해 놓으면 다른 CHILD 테이블이 다 날아갈 수도 있고, 뭐가 어떻게 지워지는 것도 모를 것이다. 

 

성능 측면에서 이해해보자면, FK는 PK만을 대상으로 만들어져야 한다. FK가 유일 인덱스가 아닌 값을 조회하게 되면 일단 성능 면에서 굉장히 떨어질 것이다. 때문에 한개의 값만 나오는 PK로 해야 효율적인 서치가 가능할 것이다.