양방향 매핑 정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료
- 양방향 매핑은 반대방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
- JPQL에서 역방향으로 탐색할 일이 많음
- 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨(mapped by : 테이블에 영향을 주지 않음)
- 1:N일 때 N인쪽에서 연관관계 다 발라주시고 양방향은 애플리케이션 개발에 실제 들어가서 고민해도 늦지 않는다.
- 할수 있으면 되도록 단방향으로 짜자, 그런데 실무에선 JPQL를 위해서 양쪽으로 걸려있는게 순조로울 때가 있다.
- 어쨌든 핵심은 단방향으로 잘 짜는 것이다.
주의사항
- 엔티티 자체를 리턴하는 짓은 하지말자 - 되도록 DTO를 만들어서 리턴하도록
연관관계 주인을 정하는 기준
- 비지니스 로직을 기준으로 연관관계의 주인을 선택하면 안됨
- 연관관계 주인은 외래키의 위치를 기준으로 정해야 한다.
다양한 연관관계 매핑
연관관계 매핑 시 고려해야 할 사항 3가지
- 다중성
- 다대일: @ManyToOne
- 일대다: @OneToMany
- 일대일: @OneToOne
- 다대다: @ManyToMany : 실무에서 쓰면 안됩니다.
- 단방향, 양방향
- 테이블 : 외래키 하나로 양쪽 조인 가능, 방향이란 개념 없음
- 객체 : 참조용 필드가 있는 쪽으로만 참조 가능
한쪽만 참조하면 단방향
양쪽이 서로 참조하면 양방향(이라고 부를 뿐 객체 입장에선 단방향이 두개)- 연관관계의 주인
- 객체의 양방향 관계는 참조가 2군데, 둘 중 테이블의 외래키를 관리할 곳을 지정해야 한다.
- 연관관계의 주인 : 외래키를 관리하는 참조
- 주인의 반대편 : 외래키에 영향을 주지 않고 단순 조회만 가능
다대일 단방향
일대다 단방향
- 지원하고 있는 기능이지만 실무에선 권장하는 방법이 아닙니다.
- DB입장에서 생각해보면 1:N관계에서 N쪽에 외래키가 들어가기 때문에
- update쿼리가 한 번 더나가야함 성능상 크진 않지만 손해긴 하다.
- @JoinColumn 넣어야 함 -> 넣지 않으면 join table이 생긴다.
- 엔티티가 관리하는 외래 키가 다른 테이블에 있음
- 연관관계 관리를 위해 추가로 update sql실행
- 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자.
일대다 양방향
- 이런 매핑은 공식적으로 존재하지 않는다.
일대일 정리
- 주 테이블에 외래 키
주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래키를 두고 대상 테이블을 찾음
객체 지향 개발자 선호
JPA 매핑 편리
- 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
-단점 : 값이 없으면 외래 키에 NULL 허용- 대상 테이블에 외래 키
전통적인 DB개발자들이 선호
- 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
- 단점 : 프록시 기능의 한계로 지연로딩 설정해도 항상 즉시 로딩됨
상속관계 매핑
- 조인 전략, 단일테이블 전략 선택 각 장단점이 있다.
- 그러나 기본적으로 조인 전략을 기본으로 생각하는 것이 좋다.
- 아주 단순한 구조와 데이터 양일 경우 단일테이블 전략을 선택하는 것도 좋다.
Mapped Superclass - 매핑 정보 상속
- 테이블 간의 상속 관계는 아니지만, 객체 간 동일한 값을 가지고 있어서 상속을 하고 싶을 경우 사용
실무에서는 가급적 지연로딩만!! 사용
다대일, 일대일은 기본이 즉시로딩이므로 LAZY로 설정해줘야 함