개나소나고생
6k
2020-07-03 08:29:34
22
2077

한방쿼리(?) VS 각 단계별 개별 처리 프로시저


안녕하세요. 이전직장에서 주로 MSSQL위주로 다루었고..주로 비지니스 적인 로직들은 내부 SQL문에 녹여서 소위 현업에는 자주 쓰이는 한방쿼리(?)를 통해 처리하였습니다.

직장을 이직하면서 현 회사는 주로 Spring Boot + MSSQL 프로시저를 활용하는데요.

프로시저를 대부분 확인해보면 단일 쿼리들이 녹여져 있고..

대체적으로 비지니스 로직을 개발 소스 영역에서 해결하려는 성향이 있더라구요.

예를 들면 페이징 처리도 소스영역에서도 해야 하고..

DB에 영향도를 줄여야 하는 관점에서 말씀을 하시더라구요.

혹시 다른 직장 개발자분들도 요새 추새가 한방 쿼리 보다는 각 단계별 처리 쿼리를 통해

구현하는지 궁금합니다.

한방 쿼리 구현시 트랜잭션 처리 관리하기 쉬웠는데.. 오히려 단계별로 쪼개서 프로시저를 작성하다보니

여간 귀찮을 뿐더라.. 트랜잭션 관리가 원할하게 될지가 의문이 듭니다.

1
  • 댓글 22

  • freestyle
    3k
    2020-07-03 08:44:34

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

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

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

  • ISA
    4k
    2020-07-03 08:54:12

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

  • 개발장
    2020-07-03 09:16:43

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

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

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

  • 앙앙이
    4k
    2020-07-03 09:30:27

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

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


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

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


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

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


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


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

  • curioustore
    1k
    2020-07-03 09:52:42

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

  • freestyle
    3k
    2020-07-03 09:58:09

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

  • ISA
    4k
    2020-07-03 11:02:31
    뭔가 이상하네요. 리드랑 쓰기가 다르다는 공감가지만 쿼리 조인하거나 서브 쿼리쓰는게 어려워서 안쓴다는건 공감가지 않는 느낌입니다...? DBA 아니라도 간단한 쿼리튜닝은 다 하지않나요?그게 어렵다면 디비설계가 잘못된거 아닌가요? Sql서버는 본질적으로 하드웨어중 보조메모리에 가까워서 뭔가 복잡한 작업을 수행하면 느려지는건 맞습니다.
  • 초보.
    3k
    2020-07-03 11:13:40

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

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


  • allinux
    1k
    2020-07-03 12:53:23

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

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

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

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

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

  • fire123
    446
    2020-07-03 13:19:47

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

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

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

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

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

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

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

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

    짜증날 뿐이죠.

  • 레버리지
    2k
    2020-07-03 13:38:46 작성 2020-07-03 13:39:10 수정됨

    통계, 리스트조회 ( SQL )

    비지니스로직 ( 자바 )

  • 콘푸로스트
    1k
    2020-07-03 13:45:20

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

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

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

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

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

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

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


  • ISA
    4k
    2020-07-03 14:34:45

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

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

  • trier
    2020-07-03 22:26:08

    ISA 

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

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


  • ISA
    4k
    2020-07-03 22:33:14

    trier//

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

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

  • ISA
    4k
    2020-07-03 22:42:09 작성 2020-07-03 22:43:40 수정됨

    Trier//

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

  • trier
    2020-07-03 23:03:00

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

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

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

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

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


  • ISA
    4k
    2020-07-03 23:42:20

    Trier//

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

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

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

  • 콘푸로스트
    1k
    2020-07-04 00:18:09

    ISA  //

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

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

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



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

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



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

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


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


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

  • ISA
    4k
    2020-07-04 06:46:23 작성 2020-07-04 06:56:24 수정됨
    콘푸로스트//

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

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

    솔직히 오라클 같은 좋은 서비스를 사용하는 환경을 간적이 없는지라 대부분 db가 웹서버와 동일한 서버에 있거나 기껏해야 aws에 있습니다 저도 실제 영향도가 크다고 생각하진 않지만 이론상으로는 연결이 많아 질수록 성능이 떨어진다고 하더군요. 그럼 현재보다 규모가 커진다고 해도 미미하다는 거군요. Db서버가 독립된 환경이라면 느리다고 생각 할 수 있지만(자본주의..) 동일 서버에서 그런 경우가 있다는 건 서버 성능이 동일하다는 환경하에 sql이 더 느린게 일반적이라는 소리가 아닐까 합니다.

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


    그냥 select에 where과 limit걸어서 가져오는 단순한 쿼리였습니다 limit로 로우수를 제한 걸 수록 sql 성능이 빨라지는건 경험 했습니다만 where로 조건을 걸어서 동일한 row를 가져오는 sql로 실험한 결과 최대 1초에서 1.5초 정도 느려지더군요. Where을 하나 넣으면 0.10 정도 평균적으로 느려지던걸 봤습니다. Db서버 성능이 아주 좋다면 무의미 할 수 있어도 별로라면 영향력 있는 요소 같습니다. 저도 이론상으론 where이랑 셀렉할때 필요한 데이터셋만 가져오는게 좋다고 알고 있는데 실제로 sql과정에서는 이해하기 힘들지만 sql성능이 줄어들더군요 더 많은 row를 읽는 문제인가 싶어서 limit를 맞춰서 걸어도 그랬습니다. 그래서 조건절로 sql상 처리하는게 성능이 떨어진다고 알고 있는거구요


    테이블을 풀스캔으로 가져온 다음에 애플리케이션에서 필터로 제거한다는 말이... 네트워크 트래픽을 더 발생시킬뿐더러, DB의 필터 성능이 절대 애플리케이션보다 떨어질 수가 없기 때문입니다.DB서버도 메모리에 자주 이용하는 데이터(블럭, 테이블)을 올려서 사용합니다. 하드디스크에 매번 읽고 쓰지 않고, 그냥 메모리에 통으로 올려서 사용합니다. 그리고 쓰기 작업도 매번 디스크에 쓰지 않고, 로그파일로 append 해놓고 배치성으로 기록하고요. 같은 스펙이라도 애플리케이션서버보다 월등한 성능을 보여줍니다.

    Db성능이 어플리케이션(언어마다 다른 걸 거 같네요.)보다 좋다는 말은 잘모르겠습니다. 하지만 db자체가 파일리딩식으로 움직이지 않는다는 생각해봐야하겠네요. 감사합니다. 같은스펙으로 월등하다는 건 다른 모든 요소를 고려하지 않는 점인지 정도가 궁금하네요.

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

    이건 페이징 성능이 아니라 offset 또는 limit 0, 10을 언급한 것 입니다. 실제로 해당 기능을 사용시 풀로 가져오는 거 보다 sql상에서는 더 느립니다. 그걸 연결해서 가져오는걸 고려하면 뭐가 더 빠를지 모르겠지만 sql상의 성능 실험은 제가 한게 아니라 외국 사람들이 실험한 것을 읽어온겁니다.


    결국 결론은 그렇게 sql속도가 느려져도 db에서 처리하는게 서버에서 처리하는거 보다 빠르시다는 소리로 이해가 되는데 맞습니까?

    그냥 제가 쿼리튜닝이 미숙해서 발생하는 문제일 수 도 있겠네요.

  • ISA
    4k
    2020-07-04 07:09:37 작성 2020-07-04 07:19:27 수정됨
    콘푸로스트//
    관련해서 자료를 찾아본 결과 그냥 쿼리튜닝의 미숙이 원인이었던거 같네요.
    Covering index를 하지 않으면 성능차이가 심해서
    30초에서 => 1초 정도이니 다음부터 쿼리튜닝 할때 고려해야겠습니다.
    즉 정리하면 where조건절이 걸릴때 마다 sql 성능은 느려지는게 맞지만 sql쿼리 튜닝을 잘하면 그걸 압도적으로 줄일 수 있다가 맞는 말이였네요 그럴 경우 유의미 할 정도로 sql시간 차이가 나지 않으니 서버에서 처리할 만한 이유가 딱히 없다는 거구요 sql상에서 처리 불가능한 복잡도를 가지지 않는한 . 결국 db를 얼마나 잘만지냐에 따라서 서버에 부담을 주냐 sql에 부담이 주냐가 갈린다는 걸로 결론 내렸습니다.

    그리고 결국 셀렉하는 row수가 늘어 날 수록 sql성능이 압도적으로 느려진다는거고 셀렉의 경우 분기 처리해서 멀티로 가져오는게 이점이 될거같네요.

    감사합니다 db에 대한 부족한 점들을 많이 배운거 같습니다.ㅎㅎ
  • ISA
    4k
    2020-07-04 11:56:03

    *//

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

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

    Mysql join vs multiple querys

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

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

  • 로그인을 하시면 댓글을 등록할 수 있습니다.