프로필사진

Go, Vantage point

가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.


Github | https://github.com/overnew/

Blog | https://everenew.tistory.com/





티스토리 뷰

반응형

 

 

 

외래키의 위치

 

 

일단 데이터베이스의 개념부터 설명하고 들어가자.

 

두개의 엔티티가  관계(연관)를 가지면 외래키가 두 엔티티중 하나에 들어가야한다.

예를 들어 프로젝트와 프로젝트 매니저 사원의 관계를 생각해보자.

 

 

프로젝트에는 단 한명의 매니저가 반드시 존재한다. (프로젝트가 관계에 완전 참여)

따라서 소수의 인원만이 프로젝트 매니저가 된다. (사원은 관계에 부분 참여)

즉, 다음과 같이 표현된다.

 

 

 

 

 

일단, 사원 테이블에 자신이 매니저를 맞고있는 컬럼이 있다고 생각해보자.

해당 컬럼은 프로젝트의 기본키를 외래키로 가져오게 된다.

그러나 소수의 사원만 매니저를 담당하므로 대부분의 사원에게는 NULL 값이 삽입되어야 한다.

수 많은 사원들의 해당 필드값이 NULL로 채워진다면, 공간을 낭비하게 된다.

 

 

 

 

 

반대로 프로젝트 테이블이 해당 프로젝트를 관리(매니징)하는 사원의 기본키를 외래키로 가지고 있다고 생각해보자.

이 경우에는, 모든 프로젝트는 한명의 관리자가 반드시 존재하므로 모든 필드의 값이 NULL이 아닌 외래키가 담기게된다.

따라서 공간의 낭비가 없다.

 

그러므로, A(0,1) - (1,1)B의 관계에서는  완전 참여하는 테이블(프로젝트)이 부분 참여하는 테이블(사원)의 기본키를 외래키로 가져가는 것이 효율적이다.  

 

 

JPA의 @JoinColumn도 이와 같이 사용해야한다.

@JoinColumn은 속성값으로 매핑해올 외래키 명을 지정할 수 있다.

만약 두 테이블 중 어느곳에 @JoinColumn을 사용할지 고민한다면, 공간적인 측면에는 완전 참여하는 테이블이 외래키를 가져가는 게 옳다.

 

 

 

참조 테이블의 제거

 

 

추가적으로 JPA 에서는 @JoinColumn 생략할 수도 있다.

하지만 이러한 경우 DB서에는 다음과 같은 비효율적인 문제가 발생한다.

 

사원과 프로젝트의 관계인 MANAGE라는 참조 테이블이 독립적으로 생성된다.

 

 

 

 

이러한 추가 테이블의 생성은 공간 낭비가 발생할 수 있다.

이러한 추가적인 결합 테이블의 생성은 JOIN 작업이라고 하는데, 성능적인 측면에서도 비효율적일 수 있다.

하지만, 자주 사용되는 경우 JOIN 테이블을 생성하는 것이 효율적일 수도 있기 때문에 분석이 필요한 부분이다.

 

 

 

 

 

반응형
댓글
반응형
인기글
Total
Today
Yesterday
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함