팀플중인데 제가 제일 기본적인 역할을 맡았던 말이죠?
아니 일단 db 어댑터가 JPA이긴한데
피드 상세정보를 보려면 피드 루트엔티티에서
피드 내용 + 피드 사진 + 피드 멤버정보 + 조회자 좋아요 정보+ 태그정보 N:N인 관계는 조인테이블까지 조인쳐야되서 총 6번이 들어가는데
그래서 생각한 방법이 조회 전용 nosql로 따로 빼버리고 엔티티 변경이 있을 때 조회전용 테이블을 업데이트하고 그냥 한방에 조회
아니면 무분별한 매핑 싹다 갖다버리고 VO객체를 ID나 필요 필드로 도메인이나 db 엔티티를 재구성
예를들면 @ManyToOne 빼버리고 MemberInfo VO 객체 또는 외래키를 빼버리고 그냥 피드 게시글이 작성자의 최소 필요 정보만 가지고 있기
또 아니면 좆같은 N:N 관계는 따로 API 콜하기
뭐 방법 없을까요? 아니면 걍 조인 6번 칠까요?
1은 과하고 2는 의미없음 루트가 다른 회원만 뺄 수 있잖아 3은 성능 고려해봐야함 조인쿼리가 빠른지 각 부가도메인 호출을 하는 게 빠른지
감사합니다
select6개 돌리던가 2tier면 걍 조인6개돌려라 nativeQuery쓰고 그게 더 빠름 후자로가면 이미 orm버린거 알지?
갑사합니당
니가 생각한 방법이 가장 좋은데 가장 손많이가고 그런 방법임 포폴에서는 비추
제가 씹좆밥이라 잘 모르는데, 그렇다고 저 게시글하나 orm으로 로딩하면 쿼리 조온나게 나가지 않나요?
혹시 제가 생각한 방법이 제글에서 어떤 건가용?
디비 분리해서 ui용도 디비 따로 관리하는거
아 넵 감사합니다 orm을 버렸다는 건 orm에서 지원해주는 로딩전략 같은 것을 사용해서 도메인 코드를 짜지 않았다는 말씀이시죠? 근데 이게 orm을 사용하면 업데이트나 조회 둘 중에 하나 포기해야되는 것 같아서 ,, 업데이트는 최상단 엔티티를 orm 관련해서 도메인 무결성을 유지할 수 있는데 이게 조회로 가버리면 염병 조인안하면 jpa 가장 기본적인 문제인 1+N 이 나오고
nativeQuery쓰던가 쿼리메소드 6개 날리면 되 OneTo이런거로 엔티티탐색하고 골머리썩히느니 난 일케함 끝까지 orm할거면 find6번하고 아니면 로우쿼리로감 nativeQuery설정하는거 찾아보면 나옴
아그래서 JDBC로 구성 중이였는데 안그래도 찾아봐서 JPQL하고 DSL 찾긴찾았습니다 참고하겟씁니다 감사합니다
괜찮은 거 같은데
감사합니당