흔히 si는 비즈니스 로직이 sql 쿼리에 있다고 하는데 잘 와닿지 않아 질문드립니다.

Question

안녕하세요.오키 게시글 보다보면 비즈니스 로직이 쿼리에 담겨있다는 글을 종종 보게 됩니다.그래서 쿼리가 굉장히 길어지고 복잡해지는 경우가 많다고 하는데,비즈니스 로직을 쿼리에 담는다는게 정확히 무슨 말인지 잘 모르겠습니다.핵심 로직은 결국 코드로 구현할 수 있지 않나요?이제 CRUD 간단히 구현하는 수준이라 그 의미를 잘 이해하지 못하겠습니다.

kenu,전독시 · Accepted Answer

sql에 case when 있으면 로직이 들어간 것으로 보이면 그런 경우입니다.from: https://gent.tistory.com/435이렇게 짠 SQL이 많을 수록 비즈니스 로직이 sql에 담긴 것입니다.물론 애플리케이션 레벨에서 구현 가능합니다.

hong킬동 · Answer

음..좀 큰곳에 운영같은거 가보면어지간한게 다 프로시저로 엮어서 돌아감 ㅋㅋㅇ

76진 · Answer

중요한 기능을 자바로 구현하는게 아니라 SQL 쿼리문(plsql) 으로 기능 구현을 하고, 자바에서는 해당 SQL 함수 호출로 개발하는 경우를 말합니다.

MSSQL 튜너 · Answer

서비스 전문 회사랑 일반 회사의 차이라고 보시면 됩니다.접속자수가 많고 개인별 트랜잭션이 많을 경우 코드 구현이 낳을수 있고요~(서비스)ERP, MES, 기타 업무 위주의 프로그램은 SQL로 구현하는게 유리할수 있습니다(SI)정답은 없지만 되도록이면 지키면서 하죠~일하는 회사 공통 기준에 맞춰서 작업하시면 됩니다~

yeori · Answer

한국에서는 "한방쿼리"라는 키워드와 밀접한 연관이 있습니다.아래의 글들을 참고하시면 배경을 이해하는데 도움이 됩니다.https://scidb.tistory.com/m/entry/%ED%95%9C%EB%B0%A9-Query%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%A7%80-%EB%A7%90%EC%95%84%EC%95%BC-%ED%95%A0-%EB%95%8Chttps://yongkyu-jang.medium.com/jpa-%EB%8F%84%EC%9E%85-%EC%97%90%ED%95%84%EB%A1%9C%EA%B7%B8-faa70332f53a예를 들어 보험 설계사들 급여와 등급을 계산하는 경우 계약 건수와 계약액에 따라서 책정되는 기본급이나 수당이 다릅니다.설계사들마다 부여받은 등급에 따라 커미션 비율이 다를 수도 있겠죠.이런걸 코딩으로 구현하면 조건문+반복문들에 해당하는데, 이런걸 비즈니스 로직이라고 합니다.미래에 바뀔 수 있는 업무 규칙들의 구현체 이걸 쿼리에 다 때려박아서 결과를 뽑아냅니다.수백라인 정도는 얘교고, 길면 수천라인도 있음.한방 쿼리의 역사이렇게 비즈니스 로직을 직접 다루는 무쟈게 긴 쿼리들의 역사를 더듬어보면 대부분 오라클 기반에서 출발했습니다(특히 PLSQL)이 솔루션이 처음 등장한게 1992년 무렵이었는데, 이 당시에는 아직 자바나 파이썬 기반의 백엔드가 없었습니다(그 무렵 다들 응애였음)클라이언트들은 사무실에서 업무를 담당하는 현업들이었고, SI 시스템은 오로지 사내용이었습니다.게다가 당시 인프라 환경도 열악했기때문에 하드디스크든 메모리든 cpu든 전부 비싸고 귀했습니다. 네트워크 통신은 뭐 더 말할 것도 없었고,이런 환경에서는 쿼리를 여러개 쪼개서 처리할 여건이 아니었기때문에 디비벤더가(오라클) 프로그래밍까지 할 수 있는 솔루션을 개발했습니다.심지어 문서 포맷팅도 쿼리로 다 해야했습니다.지금처럼 스프링이나 expressjs, flask같은게 없었으니 이사님한테 갖다바칠 보고서도 전부 쿼리로 좌우 정렬해서 이쁘게 출력해야했음.이때의 흔적이 아직도 디비 내장함수에 남아있죠. 패딩 붙이는 함수들, 좌우 정렬, 숫자에 쉼표 넣기 등등...그리고 한국에서 2000년 전후로 정부가 IT 산업을 전략적르로 키우면서 이런 기술들이 그대로 들어옵니다.자연스럽게 비즈니스 로직까지 전부 쿼리에 쓸어넣는 문화가 자리잡음.시대가 변함그러나 지금은 한방쿼리로도 해결이 안될 정도로 시스템이 엄청나게 복잡해졌습니다.보름간 기를 쓰고 업무규칙 떡칠해서 만들었다가 몇년 후에 정책이 바뀌면 쿼리를 고쳐야하는데, 그거 짠 사람은 나가고 없음.어디 잘못 건드리면 난리나니까 어지간하면 손대지 않는 보수적인 개발 문화로 이어짐(손대지 마! 그거 지우지마! 큰일나! 아무튼 건들지 마!)꾸역꾸역 쓰다가 도저히 안되겠다 싶으면 "차세대"라는 이름으로 갈아엎고 새로 만듭니다.그런데 이전에 한방쿼리 중심으로 개발했던 사람들이 또 들어가서 똑같이 만드니 같은 일이 또 반복됨.지금은 디비는 데이터 담는 용도로만 쓰자는 공감대가 전세계 개발자들에게 자리잡은 상태고, 하이버네이트같은 orm 기술이 개발된 배경입니다.

장독깨기 · Answer

비지니스 로직이란 것이 별거 아니구요,비지니스, 즉 업무가 있으면 그 업무를 위해 관리해야 할 데이터가 있을 거잖아요.이런 데이터를 잘 구조화해서 데이터베이스에 저장하고 관리 합니다.그리고, 데이터베이스 엔진은 데이터 입출력을 위해 SQL 문을 제공합니다. (다른 방법 없습니다.)근데, 데이터를 효율적으로 가져오기 위해 여러 테이블을 조인해서 가져오는 경우,SQL 문이 간혹 복잡해지고 길어지는 경우가 있습니다.이럴경우, 읽기가 좀 어렵다는 단점이 있습니다. 제가 만든 것도 몇일 지나면 헷갈립니다. ㅎ조인하지 않고 테이블 단위로 가져와서 어플리케이션에서 로직으로 처리할 수도 있습니다.이러면, 뭐가 문제가 될까요? 성능이 문제가 됩니다. 문제가 아주 큽니다.ORM 이 등장하고 한방쿼리니 뭐니해서 이를 터부 시 하는 경향이 좀 있는 거 같습니다.ORM 으로는 비지니스를 처리하는데 한계점이 분명히 있습니다.상황에 따라 사용하면 되는데요, 어느 한쪽에 편견을 갖지 마시고 두루두루 사용할 수 있는 것이 좋겠습니다.무엇보다 데이터를 구조화 하는 부분, 이 부분이 굉장히 중요합니다.열심히 하세요. :)

짱구올시다 · Answer

말씀하신대로 모두 코드로 구현이 가능하나 그 모든게 한방쿼리라는 미명 하에 싹다 짬통에 쳐박혀버린 걸 비즈니스 로직이 쿼리에 있다/한방 쿼리다 그런 식으로 얘기합니다.

omelet1 · Answer

다들 상세한 답변 너무 감사드립니다.많은 도움이 되었습니다!

흔히 si는 비즈니스 로직이 sql 쿼리에 있다고 하는데 잘 와닿지 않아 질문드립니다.

8개의 답변

Q&A 목록