글쎄요... 두 가지 모두 장단점이 있다고 봅니다. 보통 "한방" 쿼리는 조회성에서 많이 썼던 것 같은데 트랜잭션의 경우라면 보통(?) 개발자 입장에서는 자바 코드에서 하는 것이 수월하죠. 프로시저로 하면 설령 개발 단계에서 문제가 없었다 해도 실제 적용 후 에러가 나거나 하면 찾기가 매우 힘들었던 것 같습니다.

아무래도 SQL 지상주의 관점에서는, 주로 연륜이 좀 있는 개발자나 시스템 관리자들이 데이터베이스 중심에 후한 점수를 주기는 하는 것 같습니다.

아마 그래서 그 중간쯤 되는 MyBatis 같은 프레임워크에서 합의를 찾는 것 같기도 하고...

성능때문입니다. Sql자체는 한번에 하는거 보다 쪼개서 하는게 퍼포먼스가 더 잘나옵니다. 파일탐색기에서도 한번에 많은 파일 옮기는거 보다 부분 부분 옮기는게 더 빠르죠? 대부분 서버에서 처리하려는건 그걸 처리하는 하드웨어의 성능에 따라 고려한 방식이기도 합니다. Db 보다 서버가 더 빠르니까요. 대신 그렇게 처리할 경우 서버에 부담이 많이 가니 적절한 선을 찾는게 중요한거 같습니다. 저도 프로시저로 나눠서 서버에서 처리하는 걸 선호합니다

쓰기와 읽기가 별도로 고려되어야 합니다.

일단 읽기의 경우 디비내의 캐싱을 위해서 많은 조인 보다 높은 퍼포먼스를 위해 Decompose해서 실무에서 사용합니다.

보다 확장성 있는 구현을 위해 CQRS 같은 패턴을 도입하는 것이나 트랜젝션은 각각의 서비스에서 책임져야 하고, 실패할 경우, 다른 서비스에 통보할 수 있습니다. saga같은 패턴을 사용할 수 있는데, read의 값이 항상 마지막이 아닐 수 있다는 단점이 있지만, 확장성을 가지고 갈 수 있다는 장점이 있습니다.

저는 DB 를 잘 하지 못합니다.

하여 한방 쿼리할 능력 안되기때문에 프로그램단에서 처리를 합니다.

저 같은 경우 한방 쿼리를 잘하는 분은 DB 를 잘하는 분인지라 동경하는 면이 없지 않지않습니다.

하지만 한방 쿼리의 문제점이라는 글을 읽게 되다 보니 문득 이런 생각이 듭니다.

프로그램단으로 처리하는 개발자의 경우 약간의 DB 경험만 있다면 

눈에 잘 보이니 레코드 조회 건수와 항목수를 최대한 줄이는 습관을 들입니다.

한방 쿼리 내부에서 무슨 일이 일어나는지에 대해서 해박한 지식을 갖고 있지 않는 개발자의 경우  문제 해결에만 몰두 하여 매우 비효율적인 쿼리문을 작성하게 되고 그 쿼리문이 인터넷에 떠 돌다 보니 당연히 그렇게 작성하는것이 좋은것이냥 전파되어 나쁜 쿼리를 계속 양산하니 지양하자 이러는것 같습니다.

시스템 개발을 총괄하는 입장에서 양질의 한방쿼리 개발자 구하는것 보다 약간의 DB 경험을 가진 프로그램단에서 처리하는 개발자 구하는것이 인력 수급면에서 더 좋고 DB 초보자들이 똥 싸놓은것 처리하는 비용보다 싸게 먹히니 더 좋지 않을까 합니다.

수천라인을 넘겨서 분석하는데만 주단위로 깨지는 미친 한방쿼리 vs 캡슐도착증에 빠진것 마냥 모든걸 쪼개놔서 범인이 이해 가능한 수준으로 풀어서 분석하는데만 주단위로 깨지는 코드 자강두천인듯...

앙앙이님이 문제의 본질을 짚어주셨네요... 바로 인력비용! 😂

저도 ISA님 말씀처럼 성능때문에 단일로 처리하는것보다는 단계별로 쪼개서 구현하는 경우가 많습니다.

한방쿼리의 치명적인 단점은 그 쿼리가 구현된 전체 프로세스를 모른다면 수정하기가 너무나 버거워 진다는 단점때문에라도 한방쿼리는 잘 사용하고 있지 않습니다.

장단점이 있는 겁니다. 즉 적재적소에 사용하면 되는 것이지 절대적인 것은 없습니다.

보통 구축하는 시스템의 병목은 네트웍입니다.

한방쿼리의 장점은 이 네트웍의 사용을 최소화 할 수 있습니다.

쿼리들을 나눠서 서브모듈화를 하면 재활용성도 좋고 쿼리 튜닝도 용이하나 어떤 하나의 흐름을 구현하기 위해 여러번 db서버를 억세스 해야 하니 여기서 병목이 발생합니다.

물론 요즘 추세는 비싼 RDBMS를 클러스터링하기보단 저렴한 서버쪽을 클러스터링 하는 아키텍쳐를 고려하니 부하를 나누고 캐시의 경우까지 생각해보면 한방 작업을 잘게 나누어 서버쪽에 로드를 나누는 것도 좋은 방법 같습니다.

DB 여러번 액세스 하면 속도 느려지지 않나요? 한방 쿼리냐 아니냐의 핵심은 쿼리 하나를 여러개에 나눠

담느냐가 아니라, 쿼리에서 가능한 로직을 자바 소스로 대체 하는게 핵심 같습니다. 그리고 어차피 DB 조회

자체도 자바 소스에서 호출하는 거기 때문에, 트랜잭션에서 DB에 있는걸 자바로 가지고 간다고 크게 문제가

될 거 같지는 않습니다. 그게 아니면, 괜히 큰 쿼리를 여러개로 쪼개서 호출하는 방법도 있는거 같은데, 자바 

소스단으로 녹여내지 않는다면, 굳이 이해하기 어렵다고 나눌 필요는 없을것 같습니다. 실력의 문제 때문에

프로그램에서 처리한다는 것도 볼 수 있는 측면이긴 하나, 굳이 어렵게 장대한 쿼리를 짠다기 보다는 그럴

시간에 자바 비즈니스 단으로 하는게 더 수월하기 때문입니다. 물론 예전에 활동하던 개발자분들은 장대한

쿼리로 한방에 해결하는걸 보고 대단하다고 스스로 느끼는거 같기도 하지만, 다른 사람들이 보기엔 어렵고

짜증날 뿐이죠.

통계, 리스트조회 ( SQL )

비지니스로직 ( 자바 )

쿼리에서 한 방이 편합니다.

중간 다리가 이것저것 많은 것보다, 오류가 발생할 여지도 적습니다.

쿼리가 복잡하다고 말씀하시는 분들도 있는데, 그건 복잡하게 쿼리를 만들었기 때문입니다.

서브쿼리로 적절히 모듈화하여 사용하면됩니다.

원하는 데이터를 찾을 때, 그 해당 서브쿼리만 확인하면 되거든요.

쿼리를 정말 이쁘게 만들어야합니다. 이게 좀 정성이 많이 필요한 작업이긴하죠.

성능이야 상황에 따라 다르겠지만, 일반적으로 대용량 집계성 데이터가 아니면 큰 문제 없습니다.

고려해야할게 캐쉬 시스템이 있냐? 예를 들어 여러가지 정보가 아닌 단일 데이터로 여러가지 가공을 거쳐야 하는 경우가 있는데 이 경우는 한번 가져와서 그걸 여러 방식으로 가공하는게 비용이 덜듭니다. 서버 저장공간을 좀 차지하겠죠(메모리) sql 연결이 많아 질 수록 네트워크 비용이 증가한다지만 sql에서 많은 처리를 할 수 록 전체적인 퍼포먼스가 떨어집니다. Sql서버에서 작동하는 방식이 서버처리 보다 느린편이라 그렇습니다.그러니 그런 데이터를 셀렉해올때는 쪼개서 가져오는게 좋고 업데이트나 삭제 인서트 같이 데이터 크기는 크지 않은데 엑세스가 많이 일어나는 작업의 경우 합치는게 성능상에서는 좋겠죠. 서버성능 db성능 서로 어느 정도 부하를 줄지를 잘 고려해야겠죠. 그런데 윗분이 말했다 시피 서버가 더 쌉니다.

잘못 알고 있는 내용있으면 고쳐주시면 감사할거 같습니다.

ISA 

sql은 한번에 처리하는게 좋습니다.

sql을 여러번 날리면 날리는 수 만큼 IO가 발생하는데 그게 리소스 가장 많이 잡아먹습니다.

trier//

실제 경험과 괴리감이 있는 지식인거 같네요. 쿼리로 니트워크 비용이 발생한다지만 멀티쓰레드 방식처럼  너무 규모가 큰 데이터는 쪼개서 가져오는게 더 효율적이라고 알고 있고 실제 sql성능상에도 10만건에서 100만건 정도 row가진 데이터 조회하면 조건절 하나마다 성능이 급격히 떨어지는걸 경험한 입장에선 납득이 안갑니다.(그냥 sql쿼리 날리면 밑에 걸린 시간 나오는 그 시간 기준입니다.)

대부분이 흔히 where로 필요한 데이터만 가져오는게 효율적이라 말하지만 솔직히 서버 기억공간(성능) 잡아먹는 거에는 그게 맞을지 몰라도 단순 sql상에서는 오히려 where문을 거는게 더 시간이 오래걸리더군요. 서버에서 처리하는게 빠르고요

Trier//

실제로 페이징에 자주 쓰이는 offset 같은 경우도 구글에 검색만 해보셔도 영어로 된 연구결과가 많습니다. 대부분이 offset건 쪽이 성능이 심하면 4배 가까이 떨어집니다. 더 많은 데이터를 읽어들인다는 이유로요.(사실 많이 읽어들인다고 보기엔 애매합니다 그냥 오프셋 안걸고 오프셋으로 지나친 로우까지 포함해서 긁어오는게 더 빠르니까요)그러니 그런걸 서버상에서 성능저하(처리 속도가 아닌 성능)을 감수하고 페이징 하는 경우가 많이 생기는거겠죠

ISA 단순이 대용량 select의 경우 페이징 처리해서 여러번 가져가는게 좋겠죠.

그러나 글쓴이님이 말한건 트랜젝션 단위의 업무입니다.

어플리케이션에서 커넥션을 맺고 쿼리를 날려서 데이터를 받아오고 로직을 처리하고 다음 쿼리를 날리는 동안에도 트랜잭션을 계속 물고있어야합니다.

단순한 배치성 작업에는 상관 없겠지만 여러 사람이 이용하는 서비스의 경우 심각한 문제가 발생할 수도 있고

여러개의 트랜잭션을 물고 있는 것도 DB에 롤백할 데이터를 계속 저장하는 것과 마찬가지 입니다.

Trier//

그렇다면 sql은 한번에 처리하는게 좋고 그게 리소스를 많이 먹는다는건 맞다고 보기힘든 명제이겠네요. 저도 트랜젝션 관련 업무는 엑세스를 적게 할 수 록 좋다고 생각은 합니다만 본글에서 써진내용은 어째서 프로시저 단위로 쪼개어진 단일 sql 서버내 페이징 하느냐? 그리고 그런 방법으로 트랜젝션 관리가 용이하냐입니다.

즉 제가 트랜젝션을 쪼개서 처리하는게 좋다고 한건 아니라는거죠 sql자체는 프로시저로 쪼개는게 성능에 더 좋습니다...현실적으로 sql작업은 데이터를 하드디스크 같은 보조 기억장치 단에서 긁어오는 작업이고 이 과정에 뭔가 절차를 넣을 수록 당연히 느려집니다. 반대로 메모리나 cpu에 넣은 이후는 매우 빠르게 처리 할 수 있죠.단 메모리나 cpu성능에 부담이 가는게 맞는거고 그러니 양쪽 입장을 잘 고려해야한다는게 제가 생각하는 쿼리튜닝에 관한 앎입니다.

트랜젝션 관련이라면 전 잘모르겠습니다

ISA  //

[sql 연결이 많아 질 수록 네트워크 비용이 증가한다지만 sql에서 많은 처리를 할 수 록 전체적인 퍼포먼스가 떨어집니다. Sql서버에서 작동하는 방식이 서버처리 보다 느린편이라 그렇습니다]

이 부분은 좀 이상한 것 같네요. sql연결이 많아질 수록 네트워크 비용이 증가한다는 말은 이론적인 부분이고, 실제로는 영향도가 없다시피합니다.

DB서버에서 작동하는 방식은 애플리케이션서버보다 월등히 빠릅니다. 애초에 데이터를 다루기위한 소프트웨어인데, 애플리케이션보다 느릴 수가 없어요. 그래서 DB에서 일괄로 처리하는게 성능적인 측면에서도 좋습니다. 만약, 역설적으로 애플리케이션이 빠르다면, DB서버가 너무 느린게 아닌지 의심해볼 필요가 있습니다.

[ 실제 sql성능상에도 10만건에서 100만건 정도 row가진 데이터 조회하면 조건절 하나마다 성능이 급격히 떨어지는걸 경험한 입장에선 납득이 안갑니다]

이건 쿼리의 문제일 수 있습니다. 10만건에서 100만건이 되어서, 성능이 급격하게 떨어졌다는 건, 로우 한줄 한줄마다 비효율적인 작업이 들어간겁니다. 일반적으로는 데이터량이 많아졌다고해서 느려지지는 않습니다. 그리고 겨우 100만건이거든요. 데이터가 많아질 수록 느려진다는 것 자체가 대용량 집계성 쿼리로 배치가 아니면, 문제가 있는 쿼리입니다. 튜닝이 필요합니다.

[대부분이 흔히 where로 필요한 데이터만 가져오는게 효율적이라 말하지만 솔직히 서버 기억공간(성능) 잡아먹는 거에는 그게 맞을지 몰라도 단순 sql상에서는 오히려 where문을 거는게 더 시간이 오래걸리더군요. 서버에서 처리하는게 빠르고요]

이 부분도 말이 안됩니다. 당연히 where 절에서 필요한 데이터만 먼저 가져오는게 훨씬 더 빠릅니다. 테이블을 풀스캔으로 가져온 다음에 애플리케이션에서 필터로 제거한다는 말이... 네트워크 트래픽을 더 발생시킬뿐더러, DB의 필터 성능이 절대 애플리케이션보다 떨어질 수가 없기 때문입니다.

DB서버도 메모리에 자주 이용하는 데이터(블럭, 테이블)을 올려서 사용합니다. 하드디스크에 매번 읽고 쓰지 않고, 그냥 메모리에 통으로 올려서 사용합니다. 그리고 쓰기 작업도 매번 디스크에 쓰지 않고, 로그파일로 append 해놓고 배치성으로 기록하고요. 같은 스펙이라도 애플리케이션서버보다 월등한 성능을 보여줍니다.

그리고 페이징하는데 성능은 언급하셨는데, 페이징에 성능이 떨어진다면 그건 아직 페이징처리를 제대로 하지 않았기 때문이 아닐까 합니다. 단일 쿼리 기준으로 '마지막 페이지'만 아니면 페이지 성능이 떨어질 이유는 없습니다.

*//

대댓글보고 궁금한 점들이 계속 생겨서 조사해보니 데이터 베이스에 따라 많이 달라지네요.

 오라클의 경우 커넥션 비용이 타 db보다 높은 편이라 엑세스를 많이 할 수록 퍼포먼스가 저하되고 (네트워크 비용이 늘어남)mysql의 경우는 그런게 별로없어서 커넥션 릴리즈가 비교적 자유롭고 등등

Mysql join vs multiple querys

이런 경우도 나오는데 오라클의 경우 그냥 join이 빠르겠네요. 같은 관계형 db라고 비슷할줄 알았는데 각 db마다 차이가 심한편이라는걸 알았습니다.

이제 그만 찾아보고 운동이나 하러갈랍니다.