Whiteship's Note

'복잡한 로직'에 해당되는 글 1건

  1. 2010.07.07 복잡한 로직은 복잡한 DAO로 직결되는가? (6)

복잡한 로직은 복잡한 DAO로 직결되는가?

모하니?/Coding : 2010.07.07 10:14


아니지 않을까... 비즈니스 로직이 복잡하다고 해서 SQL이 복잡해 질 필요는 없다.

재고 마감 로직을 생각해보자. 모든 창고에 들어있는 모든 상품들의 전일 재고량, 금일 입고량, 금일 출고량을 가져와서 금일 재고량을 계산한다고 치자. 이걸 가지도 또 상품 카테고리 별로 묶고 창고 별로 묶어서 집계를 내야 하는데.. 일단은 그 전 단계까지만 해보자.

Location - Inventory
Item - Inventory
Item - InvIn
Item - InvOut
Item - InvDailyClosing

이렇게 관계가 맺어져 있으니 SQL로 join을 하던 sub select를 하던 어떻게든 SQL 한방으로 어떤 창고에 있는 어떤 상품의 '전일 재고량', '금일 입고량', '금일 출고량'을 한방에 가져올 수 있을 것 같다.

근데 난 그렇게 하지 않는다. 사실 그렇게 복잡한걸 만들지도 못한다. 만들라면 공부해가면서 만들겠지만 무지 오래 걸릴 것 같다. 그래서 난 그냥 자바 코드로 SQL을 대신한다.

        dao.delelteAllAt(today);

        for(Location location : locationDao.getAll()) {
            // 모든 상품 마다
            for(Item item : itemDao.getAll()){
                // 전일 재고량 조사
                double qtyStart = inventoryDao.getQtyOf(yesterday(today), item, location);
                // 금일 입고량 조사
                double qtyIn = invInDao.getQtyOf(today, item, location);
                // 금일 출고량 조사
                double qtyOut = invOutDao.getQtyOf(today, item, location);
                // 금일 재고량 계산
                double qtyEnd = qtyStart + qtyIn - qtyOut;

               나머진 생략...
            }
        }

즉 이런식으로 짠다. 굵은 글씨 부분은 DAO test를 해서 해당 기능이 내가 원한대로 동작하는지 일일히 확인해다. DBUnit을 사용해서 테스트용 데이터를 넣고 저 기능을 실행해보는 방식이다. 이렇게 구현하니까 상당히 마음이 놓인다. 저걸 만약 한방에 SQL로 구현했다던지.. 테스트 없이 구현했다면.. 글쎄.... 그렇겐 못했을 것 같다.

암튼 이래서.. 복잡한 로직을 처리하는 DAO 코드라 할지라도 단순해진다. 이런걸 디바이드 앤 퀀쿼 라고 하던가.. 몰겠다. 머라하든.

    public double getQtyOf(Date date, Item item, Location location) {
        Object result = getSession().createQuery("select sum(qty) from InvIn where date = :date and item = :item and location = :location group by item")
                .setDate("date", DateUtils.getDateOnly(date))
                .setEntity("item", item)
                .setEntity("location", location)
                .uniqueResult();
        if(result == null)
            return 0.0;
        return (Double) result;
    }

대충 이정도 코드가 생기는데.. 이정도야 뭐.. 초간단 SQL 수준 아닌가..

이렇게 짜면 걱정되는게.. 성능인데... DB에 자주 다녀올수록 더 많은 부하가 생기는건 사실이지만 어차피 복잡한 쿼리 자체도 join 여러번 하면서 부하가 생길테니.. SQL 도사가 아닌 이상 차라리 성능을 조금 포기하고 유지 보수 가능하고 알아보기 쉬운 코드로 나눠서 작성하는게 더 좋치 않을까 싶다.





top

  1. 비트겐슈타인 2010.07.07 11:05 PERM. MOD/DEL REPLY

    배치 로직이면 모르겠는데. 온라인 로직이라면 흠... (for 문의 압박 -_-)
    기본 생각은 저도 동의합니다. 덩치큰 SQL 보다는 작은 SQL을 잘게 던지는게 DB에 cpu 부하를 덜 주기도 하구, DB 캐싱도 한결 수월해질 것 같고...

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.07.07 12:51 신고 PERM MOD/DEL

    이 글이 모든 경우를 SQL 대신 자바 코드로 해결하자는 건 아니었는데... 그렇게 읽히는 분도 계신가 봅니다. 어흑..@_@

  2. Favicon of http://starplatina.tistory.com BlogIcon June 2010.07.14 17:14 PERM. MOD/DEL REPLY

    기선님 댓글 보고 좀 생각해 보니까요.

    좀 젊은 사람들 20대~30대 초초초반 사람들은 SQL 로직보다 자바 코드가 더 익숙하지 않을까 싶은 생각이 드는데요.

    저 같은 경우에도 공부를 하면서 DB 쪽은 DBA들이 하도록 하자는 생각이 좀 강하고, 그런 마인드를 가지고 있으니 비즈니스 로직을 작성을 자바 코드에서 하는 것이 쉽고, SQL에서 하면 버벅 대네요.

    업무 종류도 기존에는 c/s 환경을 web으로 바꾸는 것 이다 보니 쿼리 중심인 경우가 많았는데, 요즘 프로젝트가 또 쿼리 중심 보다는 자바 비즈니스 로직 중심인 경우도 있으니깐 그럴수도 있다는 생각이 드네요 ㅋ

    그나저나 스프링 책 언제 나오나요. 어서 재촉좀 해 보세요 ㅎㅎ

    Favicon of http://whiteship.me BlogIcon 기선 2010.07.14 17:43 PERM MOD/DEL

    흠.. 넹 하지만 group by 같은건 잘쓰면 for 루프를 줄일 수 있어서 좋은 것 같아요. 뭐.. 다루는 데이터가 많지 않으면 그냥 for 뤂 돌려도 상관없을 것 같은데.. 잘 모르겠네요. 때에따라 여러 방법이 있을텐데.. 비즈니스 로직을 무로건 SQL로 구현하는건 암튼 좀 아닌듯.. 이런 저런 상황에 따라 쉽게 바뀌는데 로직인데 테스트나 변경 편의성 등을 볼 땐 자바 코드가 좋을 듯 싶어요.

    토비님 책은 이제 3장까지 마무리 하셨답니다. 이번주에 다 마무리 하시고 출판하면 7월 말에는 정말 나오지 않을까 싶네요.

  3. Favicon of https://slothink.tistory.com BlogIcon 편현장 2010.07.16 01:25 신고 PERM. MOD/DEL REPLY

    ㅎㅎ 부디. itemDao.getAll() 의 결과가 무지막지하지 않게 나오길 빌어야겠네요^^
    저도 왠만하면 위의 예제처럼 짜서 빠르게 만들었다가 성능 문제로 최소한의 쿼리를 사용하게 변경하게 하곤 하는데요. 변경하는건 쉬운데, 문제가 발견되면 꼭. "하이버네이트라서 느린건가보다. 하이버네이트에선 해결이 안되는거니?" 라는 말이 나오는지라.. 가급적 n+1 의 문제를 안드러내려고 하죠.
    번역해주신 책에 가빈 킹이 하이버네이트의 맞는 사용자는 sql 을 잘 알며, 객체지향적으로 설계하고 싶은 고급 사용자라고 하는데 그 말이 맞는거 같습니다. 정말 좋은 프레임웍인데, 대충 쓰다간 욕을 먹죠. 에긍.. 기선님이 일하시는 곳엔 하이버네이트 등에 열린 시각들을 가지고 계신가요?

    Favicon of http://whiteship.me BlogIcon 기선 2010.07.16 11:00 PERM MOD/DEL

    앗 위험한 부분을 잘 짚어주셨군요. 하이버네이트 책 3부에 보시면 n+1 문제 해결책을 여럿 소개하고있긴한데 당장은 성능보다 비즈니스 로직 분석하고 코드로 그걸 잘 반영하고 있는지 검증하는 단계인지라.. 최적화 문제는 일단 로직 검증이 끝난 뒤에 해결해야 될 것 같습니다. (재고 마감이 좀 복잡하네요.ㅠ.ㅠ)

    흠.. 제가 일하는 곳이라.. 여긴 거의.. 제 맘대로에요.

Write a comment.