잘 와닿지가 않습니다ㅠㅠ

이 강의의 기본 흐름은, Table에서 지원하는 작업들을 어떻게 ORM에서 객체지향적으로 깔끔하게 구현해주느냐의 문제입니다.

Member와 Team 테이블이 있을 때, Member에 외래키가 있겠죠? Member 쪽이 N 이니까.

이 때 DB에서 select 를 사용할 경우 Team을 기준으로 Member와 join하든지, Member를 기준으로 Team과 조인하든지 조회할 때는 어느쪽이나 자유롭게 조회가 가능합니다.

하지만 객체지향은 그렇지가 못하죠. 

Member 에서 team을 가져오고 싶다면 member.getTeam()를, team에서 member를 가져오고 싶다면 team.getMembers() 가 가능하도록 각각 테이블에 멤버변수를 추가해주고 이를 ORM이 인식하도록 어노테이션을 붙여주어야 할 것입니다.

여기서 또 다른 문제가 생깁니다.

조회만 할 때는 문제가 없어보였지만 삽입을 할 경우 다음과 같은 코드를 만나면 ORM이 어떻게 처리해야 할까요?

team.addMember(member);

member.setTeam(team);

team에 멤버를 추가하니까 새로운 member를 DB에 insert  하거나 외래키를 update 해주고,

member에 team을 등록시켜주니까 새로운 team 또한 DB에 insert  하거나 외래키를 update 해주고..

뭔가 이상하죠?

외래키 하나로 DB는 자유롭게 양방향 탐색이 가능한것을 객체지향적으로 맞추려다보니 추가적으로 일이 생긴겁니다.

DB에서는 member 테이블의 team관련 외래키만 업데이트하는 방식 외에는 team쪽에서 뭔가 할 수 있는 방법이 없었는데, 객체지향적으로는 team쪽에서 건드려버릴 수 있는 여지가 생긴거예요.

연관관계의 주인이란 것은, 이런 경우 다른 테이블에 영향을 줄 수 있는 명령은 어느 엔티티 객체로 한정지어버릴 것인가? 하는 문제입니다.

연관관계의 주인이 Member 라면 member.setTeam(team); 만 신경을 쓸 것이고, 연관관계의 주인이 Team이라면 team.addMembers(member);만 신경을 쓰겠다는 것입니다.

전자는 DB와 일치하는 패러다임으로 member의 team외래키만 업데이트 해주면 되는 반면, 후자는 JPA가 어거지로 연결해준 것으로 team에서 수정이 시작되었는데 최종적으로는 member 테이블의 team외래키가 업데이트되기 때문에 가급적이면 전자의 방법을 취하는게 좋다고 강의에서 설명하고 있습니다

이 답변 너무 깔끔한거같습니다. 짱입니다