[일반] JPA 고민

[익명(58.29)]

엔티티 단위로 조회를 하면 보다 객체지향적으로 코드를 작성할 수 있지만

불필요한 컬럼 조회로 인한 오버헤드 증가 + 조인 시의 락 문제가 있음...

그렇다고 필요한 컬럼만 조회하자니 1차 캐시가 주는 이점을 제대로 활용하지 못한다는 단점이 있고...

목록이 아닌 단건 조회라면 엔티티 단위 조회의 오버헤드는 무시할만한 수준이려나?

어차피 인덱스가 잘 잡혀있다면 logN의 시간복잡도를 넘지 않을테고 조회 횟수는 같을테니...

내가 쓸데 없는 고민하는건가

[백갤러 1(223.39)]

조인락은 jpa랑 관계없는데 - dc App

[익명(58.29)]

아 엔티티에 락을 걸고 변경을 DB에 반영시키려는 경우를 말하는거였음 ㅇㅇ

[익명(58.29)]

업뎃할 테이블A랑 정보 조회만 할 테이블 B를 조인할 때 락걸고 가져오면 B도 불필요한 락이 걸리니까

[백갤러 2(223.39)]

진짜 뭐 한개 컬럼만 필요한데 엔티티 전체 조회를 한다던가 그런거 아니면 그정도 오버헤드는 감수할 부분이라고 생각함. 결국 ORM이 존재하는 이유도 너가 말한 것 처럼 영속성 컨텍스트가 제공하는 이점이 그 오버헤드보다 크니까 사용하는거겠지.

[백갤러 3(223.39)]

근데 연관테이블이 많은 상황에서 사용되는 필드보다 버려지는 필드가 더 많으면 프로젝션하는게 맞다고 봄. 결국 그런 상황을 좀 더 유연하게 대처하려고 Querydsl같은게 있는거니까

[익명(58.29)]

기능마다 유동적으로 다르게 하는게 좋으려나....어렵다.. 정답이 없는 문제들.. 일단 답변 ㄳㄳ

[백갤러 4(223.39)]

정 찝찝하면 프로젝션 했을때랑 안했을때 부하테스트 해보던가… 근데 뭐 웬만한 토이플젝 수준에서선 그 차이가 엄청 유의미하게 나타나진 않을걸?? 차라리 API설계를 다시 점검해보던가 그런 상황이 반복적으로 나타나면 스키마를 변경한다던가 하는게 훨씬 유의미하게 나타날듯

[익명(58.29)]

ㅇㅋㅇㅋ 사실 1차 캐시 쓰는게 거의 같은 트랜잭션 내에서의 이벤트 처리인데, 필요한 컬럼만 조회해서 이벤트에 담자니 논리적 결합이 생기고..그렇다고 주체나 대상 같은 최소한의 id만 담자니 그 외의 정보를 재조회해야하고... 그래서 고민이었슴ㅋㅋ 작성하고 부하테스트를 통해서 다시 결정하던지 해야겠다. 답변 고마워요!!