다양한 연관관계 매핑

JPA가 4가지 어노테이션을 다 제공해 준다. (디비랑 매핑하기 위해 존재)

다중성은 약간 헷갈릴 수 있음 (데이터베이스 관점으로 이해하자)

애매할 때 반대로 생각해 보자(대칭성)

다대다 는 실무 에서 안쓴다.

다대일 > 일대다 > 일대일 순으로..

단방향, 양방향

이전 시간에 배운 내용

테이블

외래키 하나로 양쪽 조인 (방향 개념이 없다)

객체

참조용 필드가 있는 쪽으로만 참조가능 (한쪽만 이면 단방향 , 양쪽이 서로면 양방향)

사실 양방향은 없다(용어가 없어서 쉽게 설명하기 위해 만듬)
사실은 단방향이 2개

연관관계의 주인

테이블은 외래 키 하나로 두 테이블 연관

객체는 A->B B->A 참조가 2군데...
그래서 외래키 관리할 곳 지정 해줘야됨.

연관관계 주인 : 외래 키를 관리하는 참조
주인의 반대편: 외래 키에 영향을 주지 않음 단순 조회

다대일 단방향

N에 외래키가 존재.

다대일 양방향

Team 객체는 단순 조회 이기 때문에 테이블의 영향을 주지 않는다 (주인의 반대편객체는)

1 대 다

일이 연관관계 주인

1 방향에서 외래키를 관리 하겠다.

Member 랑 Team 뒤집음

Member 객체는 팀을 알고 싶지않아. ( 이래서 추천하지않는 설계였나보다..)

디비 입장상 N쪽에 외래키가 들어가야되지.

List members 하나를 바꿧을때 (여기장에선 Team이 주인)
Members쪽에 업데이트를 쳐 줘야 된다.

-> 이게 1:N 단방향 매핑

외래키가 멤버 쪽에있으므로

멤버 업데이트..

문제점?

팀 엔티티를 손댔는데 왜 멤버가 업데이트되지? 헷갈릴 수 있다..
운영이 힘들어 짐

4번 실수 했을시

정리

일대다 단방향 매핑의 단점

엔티티가 관리하는 외래 키가 다른 테이블에 있어 연관관계 관리를 위해

추가로 업데이트 쿼리를 실행하기 때문에

일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

다대일 양방향 ?

1:1

일대일 관계는 반대도 일대일

주 테이블이나 대상 테이블 중에 외래 키 선택 가능

주 테이블에 외래 키

대상 테이블에 외래키..

외래 키에 데이터베이스 유니크 제약조건 추가

일대일 : 주 테이블에 외래 키 단 방향

다대일 단방향 매핑하고 똑같다.

일대일: 대상 테이블에 외래 키 단방향

일대일: 대상 테이블에 외래 키 단방향 정리

단방향 관계는 지원 X / 양방향 관계는 지원?

Locker를 연관관계 주인으로 , 위에 단방향을 뒤집은 것

외래키를 멤버쪽? Locker쪽? 어느쪽에 둬도 성립은 함 (정답은 없다)

그러나 만약에 하나의 회원이 여러개의 락커를 가질수 있으면?

Locker쪽에는 유니크만 빼면된다.

그런대 Member에 외래키가 있으면?
Locker에 컬럼을 추가하고 코드 변경 포인트가 많아진다.

멤버를 셀렉트 많이 한다 했을때
Member쪽에 Locker 가 있는게 낫다

디비 쿼리 하나로 멤버만 가져와도 락커가 잇나 없나 쉽게 가져와 성능상 이점이 있다.
(객체 입장)

대상 테이블에 외래 키 단점
JPA 프록시 객체를 만드려면 Member 객체에 Locker값이 있는지 없는지 확인해야됨
Locker를 뒤져서 있으면 값을 넣어주고 없으면 Member에 Null 넣어줌
그래서 어짜피 조회해줘야되서 지연로딩이 들어감

아직 이해가.

암튼 쿼리가 한방 더나가야되.. 어짜피

다대다

관계형 디비는 정규화된 테이블 2개를 다대다 관계로 표현 못함

연결 테이블을 추가해서 일대다 다대일 관계로 표현해야됨

객체는 컬렉션을 사용해서 객체 2개로 다대다 관계 가능 함

그래서 밑에 그림 처럼 된다.

코드로...

중요하지 않고 실무에서도 쓰면 안됀다하니 그냥 패스하는걸로..?

실전예제 3 - 다양한 연관관계 매핑