db에서 Join vs 애플리케이션에서 조합

당연하게도 모든 사건은 한쪽만보면 안됩니다.

서버ㅡ클라이언트 시스템에서 서버자원의 비용이 높기때문에 연산을 어플리케이션으로 넘기는것은

비용 효율적입니다.

특히 사용자가 많은시스템일수록 사용자 측에서 연산을 처리해줘야 서버 부담이 적긴하죠

하지만 트레이드오프로

네트웍 사용량이 증가하고

추가적인 데이터 전송과 비즈니스로직이 어플리케이션에포함되어 보안성이 하락합니다.

그러니

보안성, 네트웍, 서버비용 의 균형점을 잡아야합니다

그리고 연관관계잡으면 유연성이 떨어진다고하는데, 안잡으면 데이터 무결성을 어플리케이션이 보장해야하며, 인덱스설계가 정교하지 않으면 조인성능이 하락합니다

감안해서 선택해야합니다.

반대로 관계를 잡아두면 db탈취시 그게또 정보유출요소기도해서요 상황에 따라 골라야죠

조인 많이 씁니다...

환경을 어떻게 구축했냐에 따라 다르겠지만

제가 속한 금융권에서는 유연성이 떨어져도 대부분

연계하도록 설계되어있습니다.

이미 db서버에 있는 데이터를 조회하면서 캐싱작업이 이뤄지고 애플리케이션에서 또 한번 적재(이중 작업이 됨)후 조합하는 것은 트래픽 증가/퍼포먼스 저하 등의 문제 야기가 있습니다.

오히려 튜닝 작업을 자주해서 db효율을 높이려고 하고

 말씀주신 질문의 답변은

Pl/sql을 굳이 쓰는 이유와 비슷하다고 생각합니다

퍼포먼스가 정상적으로 나올지에 대한 개인적인 생각은 아니라고 생각합니다.

안녕하세요. dudwns328님, 공식 서포터즈 OMG입니다.
.

제 개인적인 생각을 말씀드리면

극단적인 예로, 수만건의 데이터를 퍼올리는 배치시스템이라고 가정하면 (데이터 구조가 어떤지에 따라 다를 수 있지만)수만건의 데이터를 애플리케이션에서 조합한다면 조인으로 데이터를 조회해오는 것 보다 리소스가 많이 발생할 것 같습니다.

그리고 JPA강의에서 질문을 남겨주셨으니 JPA와 관련지어 생각해보면, N+1문제를 위한 fetchjoin을 지원하는 만큼 JPA의 조인을 잘만 활용한다면 애플리케이션에서 조합하는 것만큼? 혹은 그 이상이지 않을까 싶습니다.

조인과 애플리케이션의 성능 비교를 직접 해본적이 없어 개발 경험에서 비롯했을 때는 위와 같은 생각이며,

정말 성능이 중요하다면 둘을 비교해서 더 성능이 잘 나오는 쪽을 택할 것 같습니다.

관련해서 추가로 더 의견이 있으신 분들은 댓글로 공유 부탁드립니다 :)

.
감사합니다.