항상 N : 1 단방향으로 연관관계를 맺고 N인 부분. 즉, Reply 부분을 저장할 때, 1인 부분( Post )를 조회하고 Reply 부분에 Set하고 Entity를 저장하는 것에 대해서 불편함을 느꼈다.
물론, N 부분에 Option을 설정하지 않고 null을 1부분을 null로 저장할 수 있다.
하지만 이러한 경우 JoinColumn을 이용한 결과값을 갖고올 때, Inner Join 이 아닌 Outer Join이 일어난다.
그래서 성능이 좋은 Inner Join을 위해 @JoinColumn에 nullable = false Option을 넣어준다. 다른 방법으로는 @ManyToOne에 Optional을 추가해줄 수 있다.
EntityManager를 이용하여 프록시 객체를 갖고와 N부분에 저장을 해주고 N을 저장한다. 쿼리를 보면 실제 1인 부분인 Department 부분을 조회하지 않을 것을 알 수 있다.
프록시 객체가 아닌 실제 Entity를 조회하고 저장을 하면 쿼리는 어떻게 될까?
프록시 객체가 아닌 실제 Entity이기 때문에 쿼리가 하나 더생긴다. 이 부분을 Explain 해보면
Department - 1L 부분을 조회할 때, PRIMARY Index를 타고 이 Index 같은 경우, 클러스터 Index이기에 매우 빠르다. 그 Type을 보면 알 수 있듯이, 굉장히 빠르게 찾을 수 있다.
김영한님의 답변을 듣고 직접 코드를 짜보고 해봤다. Proxy라는 객체를 직접 호출하여 해봤다는 것이 가장 값진 경험이라 생각하고 또한, 이제는 N : 1 단방향을 짤 때, 고민없이 구현할 수 있다는 자신감이 있다.