event main - detail을 1:1 양방향 식별관계로 구현했으나, JPA의 한계로 1:1 단방향 식별관계(detail -> main 참조) 방식으로 바꿈
How
event Statistics의 경우, 두 개의 컬럼을 가지고 있으나 이를 event detail에 삽입하기 위해 조회 쿼리를 보내야 하는 불필요함이 발생하며, 비즈니스 로직 및 사용자의 뷰 관점에서 판단했을 때 detail에 함께 statistics의 내용이 묶이는 것이 합리적이라 판단 하였음.
따라서 detail에 statistics가 갖고 있던 input type, input time taken을 이관하였음.
또한 event main - detail이 상호 참조가 가능한 1:1 양방향 식별관계로 구현하려 했으나, jpa의 한계 상 lazy loading이 불가능해지는 관계로 1:1 단방향 식별관계로 바꾸었음.
객체적 관점에서는 detail은 main을 갖고 있으나, main은 detail을 갖고 있지 않게 됨.
다만 비즈니스 로직 관점 및 DB 제약 조건에 따라 main과 detail은 항상 같이 있어야 하므로, 기본 키를 기반으로 서로를 조회하는 데에 아무런 문제가 없음.
Result
event statistics 삭제 후 detail로 이관하였음
event main - detail을 1:1 양방향 식별관계로 구현했으나, JPA의 한계로 1:1 단방향 식별관계(detail -> main 참조) 방식으로 바꿈
How
event Statistics의 경우, 두 개의 컬럼을 가지고 있으나 이를 event detail에 삽입하기 위해 조회 쿼리를 보내야 하는 불필요함이 발생하며, 비즈니스 로직 및 사용자의 뷰 관점에서 판단했을 때 detail에 함께 statistics의 내용이 묶이는 것이 합리적이라 판단 하였음.
따라서 detail에 statistics가 갖고 있던 input type, input time taken을 이관하였음.
또한 event main - detail이 상호 참조가 가능한 1:1 양방향 식별관계로 구현하려 했으나, jpa의 한계 상 lazy loading이 불가능해지는 관계로 1:1 단방향 식별관계로 바꾸었음.
객체적 관점에서는 detail은 main을 갖고 있으나, main은 detail을 갖고 있지 않게 됨.
다만 비즈니스 로직 관점 및 DB 제약 조건에 따라 main과 detail은 항상 같이 있어야 하므로, 기본 키를 기반으로 서로를 조회하는 데에 아무런 문제가 없음.