[문법] 연관관계 매핑 시 고려사항

서론

※ 과거에 기록한 내용에서 중요한 부분만 발췌하여 모두가 이해하기 쉽게 다시 서술한다.

 

본론

- 연관관계 매핑 시 고려사항

1. 다중성

db는 다측에 1측의 fk를 두며, 객체는 이를 따라 다측에 JoinColumn을 한다. 대부분 다대일을 많이 쓰고, 일대일도 가끔 사용하고 다대다는 절대로 안한다.

 

2. 단, 양 방향

DB는 방향의 개념이 없고, fk 하나로 양쪽에 접근할 수 있지만, 객체는 참조를 두어 직접 접근해야하고 단방향 2개가 양방향이다.

 

⇒ 다대일

1. 단방향

주인에 참조를 두고, DB는 다측에 외래키, 객체는 JoinColumn을 한다. 가장 많이 사용하는 방법이다.

 

2. 양방향

1측에 List를 두어 양방향을 만들 수 있다. 설계할 떄는 양방향을 전혀 고려하지 않아도 되고 어플 개발 단계에서 jpql 작성 시 필요하면 추가한다.

 

⇒ 1대1

주인과 부를 양쪽 어디에든 붙일 수 있다. 보통 많이 접근하는 객체를 주인으로 fk를 둔다.

 

1. 주 테이블에 외래키 단방향

멤버가 주이고, 락커가 부라고 해보자. 멤버가 딱 하나의 락커를 가질 수 있는 룰이다. 이러면 멤버에 외래키를 넣어도 되고(반드시 외래키에 UK 제약 추가) 락커에 외래키를 넣어도 된다. 멤버에 외래키를 넣는다고 하면 db에는 회원 테이블에 fk를 넣으면 된다. 마치 다대일 단방향과 유사하다.

 

→ 코드

멤버가 락커를 가지고 주인으로서 fk를 관리하기 위해 JoinColumn을 한다. 이러면 1대1 단방향이 끝난다.

 

2. 주 테이블에 외래키 양방향

양방향을 하려면 동일하게 부에 주인을 두고 mappedBy를 하면 된다. 다대일 양방향처럼 가짜 매핑은 fk에 읽기 전용으로 적용된다.

 

- 정리

1) 주 테이블에 외래 키 단방향
2) 주 테이블에 외래 키 양방향
3) 대상 테이블에 외래 키 단방향
4) 대상 테이블에 외래 키 양방향

1대 1에서는 주인과 부의 경계가 모호하여 4번은 2번을 뒤짚은 것일 뿐이고, 3번은 처리할 방법이 없다.

 

✅ 어디에 주인으로 해서 외래키를 두는게 좋을까?

단방향으로 만들고, 더 많이 조회되는 곳에 외래키
혹은, 둘 중 나중에 다측이 될 것 같은 곳에 외래키

객체 지향적으로 참조를 고민하여, 대상을 가져야 할 곳 (ex, 사람이 키를 가진다.)에 외래키를 두면 된다. 더 많이 조회될 곳에 외래키를 둔다.

 

⇒ 다대다

실무에서 다대다는 사용하면 안 된다. 매핑 테이블에 추가로 넣을 필드가 많이 발생하는데, 다대다로 하면 할 수가 없다.

 

→ 극복법

매핑 테이블을 만들고 매핑 테이블을 엔터티로 승격한다. 매핑 테이블인 memberproduct를 실제 엔터티로 승격한다.

 

매핑 테이블이 다측으로 양쪽의 JoinColumn을 한다.

 

1측 입장인 회원과 product는 onetomany mappedby를 하면 된다.

 

🚨 주의사항

db 개념에서는 매핑 테이블을 만들면 대부분 pk 2개를 묶어서 pk로 사용한다고 배웠다.  

 

하지만, 실무에서 pk는 의미 없는 값으로 하는게 좋다. 따라서 새로 pk를 만든다.

 

- Mapped Superclass

name이라는 공통 필드가 생겼다. 그래서 이를 부모 클래스에 두고 상속해서 쓰고 싶다. (BaseEntity의 생성일, 수정일)

 

DB는 완전히 다르게 있다. 부모 자식 관계가 아니고 공통 정보를 가지고 있을 뿐이다.

 

→ 예시

우리는 모든 테이블에 등록한 사람, 날짜라는 공통 필드를 가지고 싶다. 그러면 이 필드를 모든 테이블에 다 넣어야 한다.

 

→ MappedSuperclass

BaseEntity를 추상으로 만들고 공통 속성을 넣고, 모든 객체에 Base를 상속받는다.

 

→ 실행

상속 받은 클래스에서 필드를 가지고 있다. BaseEntity는 따로 테이블이 생기지 않는다.

 

상속 관계일 경우 부모에만 상속을 받으면 된다.

 

✅ 실무에서 상속을 쓰나

데이터가 억 단위라면 테이블을 단순하게 유지하는 게 좋아서 상속을 쓰지 않고 다 분리한다. 하지만, 작은 프로젝트에서는 쓴다. 처음부터 모든 어플이 다 큰 것이 아니므로 상속을 쓰다가 나중에 분리하면 된다.