양방향 연관관계와 연관관계의 주인1 - 기본

단방향->양방향 : 테이블 변화❌

FK하나로 테이블의 양방향 연관관계 조회가능!⭐️⭐️

MEMBER 테이블에서 현재 소속된 팀을 알고 싶으면 MEMBER의 TEAM_ID(FK)를 알고 싶으면 TEAM의 TEAMID(PK)와 조인하면 된다. =>MEMBER 테이블의 FK를 TEAM 테이블의 PK와 조인하면 어느 팀 소속인지 알 수 있다! 반대로 TEAM 테이블에서 현재 팀에 소속된 멤버들을 알고 싶으면 현재 나의 PK(TEAMID)와 MEMBER의 FK(TEAMID) 조인하면 된다! =>TEAM 테이블의 PK를 MEMBER 테이블의 FK와 조인하면 현재 팀소속 멤버들을 알 수 있다!

양방향 관계에서 중요한 것은, FK하나로 양방향에 다 있는 것이다. 사실상 테이블의 연관관계는 방향이라는 개념이 없다. FK 하나 넣으면 양쪽 테이블 모두 조회가 가능하다!

예전에는 Member에서는 Team를 참조할 수 있었지만 그 반대로 Team에서 Member로는 참조할 수 없었다. 그래서 Team에 members라는 컬렉션(리스트)를 넣어주어야만 Team에서 Member를 참조할 수 있다.

양방향 연관관계 1. 객체 : 양쪽 객체 모두 참조관계(객체 또는 컬렉션) 셋팅 2. 테이블 : 한쪽에 FK 넣어주면 됨!

연관관계의 주인과 mappedBy 왜 Member에는 @JoinColumn으로 하고, Team에는 mapped By로 하는 거지? =>객체와 테이블 간의 연관관계를 맺는 차이를 이해해야 한다!

🧐 다른 팀으로 옮기고 싶을 때 Member의 team을 바꿔야할까? Team의 members 리스트를 바꿔야할까? DB 입장에서는 FK값만 업데이트 되면 된다!

둘 중 하나로 외래키를 관리해야 한다! FK가 있는 쪽이 주인이고, 주인만이 FK를 등록, 수정할 수 있다! 주인이 아닌 쪽에 값을 넣어봐야 아무 일도 일어나지 않는다!(조회는 가능) 주인 : 진짜 매핑, JoinColumn(..), FK 있는 쪽(다) 주인 반대편 : 가짜 매핑, mapped By(..), FK 없는 쪽(1)

FK가 있는 Member가 주인이면 TEAMID는 Member 내에서 존재하는 의미있는 필드 데이터이다! 팀 바꿀 때는 그냥 TEAMID(FK)만 바꾸면 된다. 그래서 FK가 있는 쪽을 주인이라고 하고, 주인이 FK 관리(등록, 수정)한다!!!!!!! =>더 직관적이다! 현재 회원의 팀을 바꾸는 것이기 때문에 변경을 하는 주체도 회원(Member)다! Member 엔티티의 테이블에서 TEAMID 관리한다.

FK가 있는 Member가 아니라 Team을 주인으로 하면 팀을 바꿀 때 Team의 members 값이 바뀐다. 이는 곧 MEMBER 테이블에도 업데이트 쿼리가 나간다. Team : Insert 쿼리, MEMBER : Update 쿼리