작성
·
1.7K
29
좀 엉뚱한 질문일수도 있습니다만 궁금해서 질문드립니다.
연관관계의 주인이라는 개념에서 주인이 아닌쪽에는 mappedBy 로 지정한다. 고 설명을 해 주셨잖아요.
그런데 OneToMany 양방향연관관계에서 주인이 아닌쪽에서 mappedBy 로 지정할 수 있으면 좋을 듯 한데 왜 spec에서는 지원하지 않는 것일까요?
그래서 강사님도 이건 야메로 되는거라면서...@JoinColumn(insertable=false, updatable=false) 로 하면 된다고 말씀주셨습니다만 이해는 갑니다만 spec 에서 @ManyToOne 에도 mappedBy를 사용할 수 있게 했으면 일관되게 정의할 수 있을텐데 하는 생각이 들었습니다.
@ManyToOne 에는 왜 mappedBy 속성이 없는지 아시면 알려주세요.
답변 3
31
2019. 12. 20. 00:54
안녕하세요 안용상님^^ 좋은 질문입니다.
질문을 정리하면 "양방향 연관관계에서 @OneToMany는 mappedBy 속성이 있는데, @ManyToOne은 왜 mappedBy 속성이 없나요?" 가 되겠네요.
여기에는 다음과 같은 이유가 있습니다.
1. 관계형 데이터베이스 테이블은, 서로 일대다 다대일 관계일 때 항상 다(N) 쪽에 외래 키가 있다.
2. 외래 키가 있는 곳을 연관관계의 주인으로 정하는 것이 직관적이고, 성능상 유리하다. (제가 항상 강조하는 연관관계의 주인은 외래 키가 있는 곳으로 정해라! 법칙입니다.)
이 두가지를 기반으로 이야기를 풀어가겠습니다.
일대다, 다대일의 양방향 연관관계는 연관관계의 주인을 어디로 두는 지에 따라 다음 2가지로 풀 수 있습니다.
A. 다대일(Member), 일대다(Team) 연관관계의 주인은 Member (정상 매핑)
B. 일대다(Team), 다대일(Member) 연관관계의 주인은 Team (야매 매핑)
여기서 A는 정상 매핑을 사용하면 되고, B는 속칭 야매 매핑을 해야 합니다. A는 연관관계의 주인이 자기 테이블의 외래 키를 관리하기 때문에 위에서 설명드린 2번 법칙에 만족합니다. 반면에 B는 연관관계의 주인이 다른 테이블의 외래 키를 관리해야 하기 때문에 2번 법칙을 만족하지 않습니다.
결론적으로 양방향 연관관계는! 항상 A를 선택하는 것이 설계의 직관성과 성능 모든 면에서 이점을 가져 옵니다. 반면에 B를 선택하면 A에 비해서 얻는 이점이 없습니다. 따라서 이 부분은 거의 선택의 여지 없이 A를 방식을 사용해야 합니다.
mappedBy를 스펙에서 양쪽에 다 풀게되면 개발자가 A가 아닌 B를 선택할 여지를 열어주게 됩니다.(여기서 B라는 것은 야매 매핑이 아니라, 연관관계의 주인이 다른 테이블의 외래 키를 관리하는 것을 말합니다.) 이것은 A를 선택하면 깔끔하게 해결되는데, 오히려 혼란만 가중하게 되는 것이지요.
야매 매핑은 이런 것도 가능하다고 개념적인 설명을 드린 것이고, 강의에서도 설명드렸듯이 실무에서는 A 방식을 선택하시면됩니다^^
감사합니다.
5
4
2019. 12. 20. 16:22
네. 마치 옆에서 설명해주는 듯한 친절하고 자세한 설명이네요.
스펙에서 강제한 이유가 있군요. 덕분에 몇 일동안 구글링 하면서 궁금했던 내용을 한번에 해결할 수 있었습니다. 고맙습니다.