Querydsl4RepositorySupport 관련 질문을 드립니다.

네 잘 찾으셨습니다^^

감히 의심해서 죄송합니다..

영한님의 jpa로드맵강의도 다 들어서.. 어느 편에서 말씀하셨는지 까지는 기억이 안나는데요.

거의 대부분의 update를 

save로 하신다고 언급하셨던 것으로 기억합니다. (제 기억이 맞다면요..)

저도 어드민 같은 경우는 save로  최근에 개발을 했는데요.

서비스에는 save를 쓰기보다.. 직접 querydsl 로.update쿼리를 날리는게 좋다고 생각이 ... 들더라구요 ㅠㅠ

실제로 어드민 시스템이 아닌곳에서도 (예: 배민앱 API과 같이 트레픽이 많은 서비스) 실제로 entity만 감지해서 save로 진행하는지 궁금합니다..

안녕하세요. thham님

데이터 변경에 대해서 궁금하신 것이군요.

활용1편에 상품 수정, 변경 감지와 병합 부분을 다시 한번 복습해주세요^^!

그리고 대량의 데이터를 변경할 때는 직접 update하는 것이 맞습니다.(벌크 연산)

감사합니다.

안녕하세요 영한님.

말씀하신 활용1편 상품수정, 변경감지 쪽 강의를 다시 복습했습니다.

다만 아직도 변경감지를 위해 select 후 update 두번의 connection이 이루어지는게 의문입니다.

준영속상태의 객체일경우 결국 id로 findone 으로 영속성태로 만들고 값을 셋팅하고

변경감지만으로 update를 한다 혹은 머지를 이용한다.

하지만 이렇게 하면 결국 하나의 사용자 request가 select,update 두번의 db요청을 보내는 것인데..

이럴 경우 update 하나만 요청하는게 더 유리한게 아닌지 여쭙는 것이었습니다.

위 답변에서 말씀하신 대량의 데이터를 변경할 때 직접 update하는게 맞다고 하셨는데요.

말 그대로 대량의 데이터를 처리하는 것 뿐만 아니라

트래픽이 많이 일어나는 서비스에도 직접 update하는게 맞다고 말씀하신걸로 이해하면 됩니까??

계속 같은 질문을 하고있는 것 같아 죄송합니다.

말씀하신 활용1편 변경감지 여러번 돌려봤지만.. 더 돌려보겠습니다.

안녕하세요. thham님

어떤 질문인지 이해가 되었습니다.

당연히 생각하신 것 처럼 update만 하는 것이 성능에는 더 나은 선택입니다.

그런데 성능에 대한 부분은 암달의 법칙이라는 것이 중요합니다.

전체 애플리케이션에서 실제 병목이 되는 부분을 최적화해야 최적화가 되는 것이지요.

비즈니스 상황에 따라서 다르겠지만, PK를 기반으로 데이터를 조회하는 것은 성능에 영향을 거의 주지 않습니다. 실제 영향을 주는 것은 복잡한 조회 쿼리나 대량의 배치 쿼리들이 영향을 주게 되는 것이지요.

실제 JPA를 사용하는 대부분의 회사에서는 select , update를 기본으로 사용합니다. 그리고 정말 성능 최적화가 꼭! 필요한 곳에서만 벌크연산(update만 처리)을 사용해서 update합니다.

감사합니다.

안녕하세요 영한님ㅎ

항상 이시간쯤.. 답글을 주시더라구요 'ㅅ'..  

저도 이제 말씀하신 부분들이 명확하게 이해되었습니다.

암달의 법칙을 말씀해주시니 더욱 이해가 쏙 들어오고,

그동안 제가 작은 포인트에 많은 공을 들인게 아닌지 생각하게 되네요 ㅎㅎ

저도 앞으로 변경감지를 잘 써보겠습니다 ㅎㅎ

언제나 좋은 강의 감사합니다.!!

질문 해결처리 하겠습니다.