서비스 로직 위주 vs 쿼리 위주

Question

스프링 위주로 공부하다가 최근에서야 db에 관심을 가지고 있습니다. 현재 si회사에서 근무하며 mybatis를 쓰고 있는데, 추후 jpa도 공부해가며 이직을 준비하려고 해요. db쪽을 보다보니 쿼리에서 처리할 수 있는 일이 매우 다양하던데 로직을 서비스나 쿼리 둘중 어디에서 처리하시는 편일까요? 쿼리위주로 문제를 해결하다가 jpa를 사용하면 익숙해지는데 시간이 걸릴까요?

니가살아봤자100년 · Answer

저는 로직 선호 합니다. 누가 프로시져나 db로 한건 잘 이해가 안가는데, 서비스단은 짧은시간 안에 이해가 가거든요. vo 나 서비스 이름, 어디서 호출 됬는지를 유추하면 남이 짠게 잘 보여서요

babydok · Answer

Bisiness Logic은 Service에 두는 것을 선호합니다.물론 그때그때 상황에 따라 다르지만요.

okky2dokky2 · Answer

저는 비즈니스 로직은 서비스단에서 처리하는걸 선호합니다.다만, SI시면 분명 쿼리 단에서 모든 로직을 처리하려고 하시는 시니어 분이 계실겁니다. 배워두면 좋습니다.

개나소나고생 · Answer

JPA도 결국 쿼리 입니다.참고로 말씀드리면 현 시점 개발 트랜드의 경우 한방 쿼리를 통한 해결 보다는 최대한 쿼리 간단하게 만들어서서비스 로직으로 해결하는 방향이 많습니다.

charlatan · Answer

상황과 목적에 맞게 선택하면 되는 것이고 어느 한가지로 통일해야 한다는 고정관념은 버리는게 좋을 것 같습니다. 일반적으로는 서비스 클래스에 로직이 있지만... 데이터를 가져올 때 SQL로 한번에 가져오는 것이 더 나을 때도 있고, 이미 복잡한 로직이 구현된 프로시저를 사용할 수도 있겠고요...

장독깨기 · Answer

비지니스용 어플리케이션의 로직은 대부분 데이터베이스 구조에 있다 생각하는게 좋을 거 같습니다.SQL 문이든 JPA 든 이는 데이터베이스를 인/아웃하는 수단 일 뿐입니다.실제, JPA 로 엔티티 와 그 관계를 작성하면 JPA 는 그걸 바탕으로 SQL 문을 만들어 데이터베이스에 요청합니다.로직을 서비스나 쿼리 둘중 어디에서 처리하시는 편일까요?이건 상황에 따라 다를 것 입니다.쿼리로 처리할 수 없는 로직도 있을 수 있고, 쿼리에서 처리하는 것이 효율적인 경우도 있을 것 입니다.가령, 사용자 접속을 시간대별로 보고 싶다, 사용자 접속 로그는 만건이 있다.첫째, 이 접속로그 데이터를 전부 어플리케이션으로 가져와서 시간대별로 분류하고 누적을 할 수도 있습니다.둘째, SQL 문으로 시간대로 그룹핑을 해서 가져올 수도 있습니다.어케 해야 할까요? 둘째로 해야 합니다.이유는 무엇입니까. 첫째는 만건의 데이터를 가져와야 하니 네트웍 비용이 그 만큼 많이 듭니다. 시간도 오래걸리겠죠.둘째는 어떻습니까? 시간대 24건만 가져옵니다.이렇게 상황에 따라, 성능, 비용 이런 것들을 고려해서 효율적인 방법으로 처리를 해야 합니다.그니까, 선호의 문제가 아니라, 비용을 고려해야 한다는 의미 입니다.물론, 비용에 큰 차이가 없다면, 선호하는 것으로 처리해도 무방합니다.쿼리위주로 문제를 해결하다가 jpa를 사용하면 익숙해지는데 시간이 걸릴까요?데이터베이스를 잘 이해하는 분들은 JPA 같은 ORM 금방 합니다.그렇지 못하는 분들은 헤매기 딱 좋고 시간도 오래 걸립니다.제일 중요한 것은, 비지니스를 분석해서 데이터 모델링, 즉, 구조화를 하는 것입니다.이 부분 굉장히 중요합니다. 이거 잘 하는 분들 몇 명 못 봤습니다. ㅎ열심히 하세요. :)

펭귄속 온천 · Answer

옛날에는 SQL만 알면 개발할수 있다. 프로시저만 알면 된다! 라는 말이 있을 정도로디비, 쿼리, 프로시저에 비즈니스 로직을 많이 넣었고실제로 00년대 후반에 프로시저를 사용한 많은 프로젝트가 있었고그때 개발을 시작하시고 지금 PM을 하시던 분들중에 아직 프로시저가 최고라고 하시는 분들이 계십니다.데이터베이스 중심 아키텍처에 대해서 오랫동안 고민해왔고제 경험과, 다양한 책, 다앙한 블로그등을 통해 내린 결론은 아래와 같습니다.쿼리로 구현하다보면 여러가지 업무를 한번에 조인해서 가져오는 경우가 있어요코드단에서 객체 지향적으로 코딩하기 어려움프로시저나 디비에서 뭐 하나 바뀌면..해당 테이블 쓰는 쿼리, 프로시저는 전부다 찾아 들어가야함.여러가지 업무가 섞여 있어서 단위테스트, 테스트 코드 작성의 어려움성능 이슈, 확장의 이슈사용자가 많은 서비스 일 경우,,,다수의 사용자가 동시에 10초짜리 쿼리를 조회한다고 하면 디비가 부들부들 거리겠죠그런데 디비의 스펙은 쉽게 업,다운 하기 어렵습니다.하지만 코드는 수평확장이 가능합니다. 서버만 하나 더 띄우면 되니깐용하지만 디비, 프로시저에 넣는것도 나름 장점이 있습니다.배포가 편함비즈니스 로직을 수정한 후 서버를 내렸다 올리거나, 젠킨스를 돌리거나 등의 행동이 필요 없음프로시저만 수정하면 되니깐하지만 요즘에는 워낙 배포자동화가 잘되어 있음하지만 제일 중요한건...진행하시는 프로젝트의 성격인듯 합니다.쿼리로 하는거, JPA로 땡겨오는거 각각 장단점, 성능 등이 있어서어떤 도메인을 하시는지, 어떤 고객과 일을 하는지에 따라서쓰셔야해요..쿼리로 하는거 안좋다고 요즘 억지로 JPA로 해서 이상하게코드 늘어놓는 주니어들이 많은데..각 상황을 잘 판단해서 :) 하시면 좋을듯 합니다.

서비스 로직 위주 vs 쿼리 위주

7개의 답변

Q&A 목록