mapped By는 우리가 JPA 를 통해 양방향 연관관계를 구현 할때 사용된다.
먼저 결론을 말하면,
mapped By 는 객체지향언어를 가지고 관계형 데이터베이스의 연관관계를 맞추려고 하면서 생겨나는 부작용을 막아주는 역할을 한다.
객체지향언어와 DB(RDB) 는 명확히 다르다.
그중 하나인 연관관계 관점에서 보면 , DB는 fk를 통해 서로 다른 테이블간의 양방향 조회가 가능하지만 , 객체는 양방향 조회를 하기 위해선 참조가 2개가 필요하다.
일단 꾸역꾸역 구현을 해보자.
강의와 강의평가는 1:N 관계이고 , 양방향 연관관계를 맺도록 이렇게 설정 해주었다.
여기서 문제가 발생한다.
두가지 상황을 예로 들겠다.
-
강의평가를 누가 새로 작성을 하였다고 가정. (EvaluatePosts 가 변경)
-
강의명이 변경 되었다고 가정. (Lecture 가 변경)
먼저 DB 입장에서는 각 테이블에 변경 또는 추가된 정보를 넣고 , 필요할 때 외부키를 통해 연관된 테이블에 접근 할 수 있다.
하지만 객체지향언어에서는 1번일 경우에 EvaluatePosts 를 업데이트 해줘야 할것이고 , Lecture 에서 가지고 있는 객체 List< EvaluatePosts > 에도 추가된 강의정보를 더해주어야한다.
반대로 2번 경우에는 Lecture 변경된 부분 업데이트 해줘야 할것이고 ,
EvaluatePosts 에서 변경된 Lecture 에 관한 부분도 업데이트를 해줘야 한다.
이러한 부분은 DB의 특성인 연관관계를 객체지향적으로 접근 하려다보니 발생한 것이다. DB는 양방향 접근이 가능하지만 객제지향언어는 말이 양방향이지 , 결국 참조는 단방향으로 이루어지기 때문이다. (서로를 참조하는 식)
그래서 JPA 에서는 야! 너 둘중에 한명 대장 정해서 , 한쪽만 변경할수 있게 하고 다른 한쪽은 수정할수 없어. 대신 조회는 가능하게 해줄게! 라는 어떤 룰을 정해논것이다.
우리는 이룰을 통해 더이상 양쪽부분중 한부분이 바뀔때마다 양쪽부분 모두 수정할 필요가 없어진다.
대장이라는것이 연관관계의 주인이고 , 연관관계의 주인인 테이블이 바뀌면 다른 한쪽에서는 JPA 가 내부적으로 FK 를 업데이트한다.
결국 mappedBy = "lecture" 라는 것은 EvaluatePosts 에 lecture 라는 컬럼에 의해 관리가 된다는 뜻이다.
여기서 한가지 더 , 사실 연관관계 주인을 누구로 설정을 하든 상관은 없다. 다 돌아간다.
하지만 DB에 최종적으로 들어갈때에는 외래키가 있는 테이블이 업데이트가 된다.
이를 다시 생각해보면 외래키를 가지고 있지 않은 테이블에서 연관관계 주인을 가지고 있을경우에는 Lecture 에서 변경이 되어서 Lecture 테이블이 수정되었는데 결국에는 EvaluatePosts 테이블에서 외래키를 업데이트 하게 된다.
이보단 외래키를 가지고 있는 입장에서 한다면 EvaluatePosts 가 생성 되고 업데이트 될때 마다 같은 테이블에 있는 lecture (FK) 가 업데이트 되는게 원래의 DB 의 패러독스에도 그것이 맞고 더 권장된다.
우리는 mappedBy 를 통해 양쪽 참조가 되어있는 객체를 한쪽만 신경 쓸 수 있게 되었다.
참고로 연관관계의 주인이 아닌 쪽은 수정이 불가능 하고 , 조회만 가능하다.
