자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 6. 다양한 연관관계 매핑

다양한 연관매핑을 알아보자고 했는데 사실 다대일, 일대다 일대일, 다대가가 전부다. 특히 거의 다대일만 쓰고 다대다는 쓰지 말자. 그럼 어떻게 해야하는지는 이따 나온다.

 

다대일 방

db의 경우, 방향이라는 개념이 없고, 다른 테이블이랑 연관하려면 자바 객체와 달리 한쪽만해도 연결이 된다. join을 그쪽으로 하면 그냥 된다. 그래서 객체 연관관계와 테이블 연관관계의 차이가 생기는 것.

근데 team는 가지면 안되냐? 할 수 있지만 team에 새로운 member를 넣을때마다 안은 리스트로 만들어서 증가해야 하고... 거기다 그걸 위한 새로운 team을 만든다고 해도 그건 중복이다. 그냥 설계가 잘못된거임. 그래서 db 설계상 team쪽에 들어갈 수 없다.

 

여기까지 다대일은 전에 배운 내용이다. 일대다부터 새로운 내용들임.

 

일대다는 공식으로 지원하기에 설명은 하지만 추천하지 않는 방법.

 

테이블 상으로는 db설계 문제 때문에 팀 정보는 여전히 member에만 있지만 그래도 난 일대다를 쓰고싶다고 해서 자바 객체에는 team에 member가 있는 걸로 작성한다.

 

제대로 작동은 하지만 2가지 문제가 있다. 일대다라서 team에 대한 정보는 다른곳에 있는데 내 쪽에서 업데이트 하고 싶다고 하니 db는 그 다른곳에 있는 정보를 한번 더 불러와서 업데이트 해야 하기 때문에 낭비가 있다. 물론 요즘에 이런 sql문 하나쯤이야 얼마나 걸리겠냐만.. 그래도 손해는 손해. 두번째는 가독성 문제. 팀에서 멤버를 불러와서 팀을 수정하지?? 같이 이해가 힘들 수 있다.

사실 db를 보면 member가 team을 굳이 알아야 할 이유는 없다. 하지만 member에 있음으로 해서 이런 여러 이득을 취할 수 있으니 트레이드 오프 관계라고 함.

 

 

참고로 일대다를 한다고 하면 @JoinColumn을 해줘야 한다. 안그러면 참조용 테이블이 따로 만들어짐. 상관은 없지만 하나 더 생긴다는게 귀찮아진다..

 

 

아까까지는 일대다 단방향을 했지만 일대다 양방향도 억지로 지원은 할 수 있다. 테이블이 아주 복잡해질 때 쓸 일이 있지만 가급적이면 쓰지 말자.

 

 

일대일은 반대도 일대일. 이런걸 쓸 때도 있다. @ManyToOne 하는거랑 비슷함.

일대일이라 외래키가 어디있든 상관없음.

양방향만 해보자. 진짜 별거 없다.

 

 

이건 아얘 지원이 안됨.

 

다른쪽에 외래키를 넣어도 됨. 어디에 넣을지는 미래를 예상하거나 각자의 철학에 따라

 

지연 로딩으로 설정해도 즉시 로딩되는건 자바 객체와 db 테이블과의 다른점 때문임. 자세한건 나중에.

 

다대다는 그냥 쓰지 말자.

자바 객체는 다대다로 만들 수 있는데 db는 다대다가 구조상 불가능해서 중간에 테이블을 자동으로 만들어서 관리한다. 근데 이게 각자의 fk를 pk로 하고 있어서 뭔가를 더 추가 못하고, pk가 비즈니스 상 중요한 정보라 제약 조건이 심하게 걸림.

그래서 다대다를 사용해야 할 때는 일대다, 다대일로 쪼개서 사용하자.

그럼 pk는 비즈니스와 관계 없는 값이기 때문에 제약도 없어지고 뒤에 컬럼을 더 추가해서 정보를 넣어줄 수도 있다.

 

 

다음은 실전 내용

 

@ManyToMany는 실습이라 써보지만 실무상에선 쓰지 말고 나눠서 쓰자.

 

@ManyToMany의 주인 객체는 해줘야 할 게 많다.

 

 

잘 보면 @ManyToOne에는 mappedBy가 없는데 @OneToMany에만 mappedBy가 있다. 즉, @ManyToOne을 주인으로 쓰라는 암묵적인 추천이다..