처음에는 단순하고 편리하다라는 장점만 생각했거든?
물론 영속성컨텍스트랑 지연로딩으로
쿼리를 여러번 보내지 않는다는것은 훌륭하다고 생각했음
왜 결국 가장 좋은개선은 DB의 접근방식이니깐?
-----이게 싸피때의 생각--------
근데 결국 더티체킹으로 객체의 변환을 감지해서
디비에 반영한다면 일관성이나 변경감지에 따른
오버헤드가 일어나지 않을까?
이게 데이터가 복잡해지고 클수록 심해질것같은디
N+1같은문제는 패치조인을 사용한다는데.
뭔가 성능적으로는 그냥 쿼리치는게 훨씬 나아보인다 말이지
현업에선 쿼리도쓰고 jpa도쓰나
- dc official App
저는 주니어인데 상황에 따라서는 쿼리를 씁니당
일관성은 어느 레벨이냐에 따라 다른데 락 잡을수도 있고.. 배치 잡 같이 대용량 쓰기 필요하면 jdbc로 직접 꽂긴함
아 씨발 공부하면 할수록 왜케 좆같은 상황들이 많노 9등급대가리로 개발하기 힘드네 - dc App
저도 응애인데, 직접적으로 관계를 맺어버리면 나중에 처리할때 추가적인 쿼리문이 나갈 수도 있다고해서 실제 관계는 맺지않고 id로 개별 Join걸어서 가져오기도 함다.
그거 대기가 맨날 말해줘서 알고는 있는데 그 줄타기가 어려움 ..즉 적절한 트레이드오프 - dc App
줄타기 잘 생각하다가 회사 들어가서 거기에 맞게 적응하면 댐
근데 대부분의 DB에서는 어차피 일관된 반복읽기 수준으로 맞춰놓고 트랜잭션 진행하지 않나? 복잡한 상황이면 또 모르겠다만.. 정합성이 필요하다면 락을 걸면 될 것이고
쌩쿼리 날리는게 영속성 컨텍스트 생성하고 스냅샷 비교하는거보다 당연히 오버헤드가 적긴 하겠지만