정보과학 IT

Business Logic(비즈니스 로직) - DB or App ..

물곰탱이 2013. 11. 21. 11:22

Business Logic(비즈니스 로직) - DB or App ..

 

2011-07-03 14:14:07
비즈니스 로직을 전부 패키지나 오라클 프로시저로 처리한다면...

궁금한 것이 있어서 여쭙습니다.

비즈니스 로직을 자바로 처리하지 않고
전부 오라클의 패키지나 프로시저로 구현해서
호출했을 때의

장/단점이 있나요?

저는 프로시저나 패키지를 잘 안 써봤는데

지금 일하고 있는 회사는 돈하고 관련된 회사라
전부 오라클 패키지/프로시저에 비즈니스 로직을 구현해놨네요

이게 속도때문에 그런건가요, 아니면 보안때문에 그런간가요?

자바로 해도되지 않을까요?



 

  • 해당 팀의 팀장과 엔지니어의 의지에 달려있습니다.
    어느 게 쉽다 편하다는 경험에 의존하는 경우가 대부분입니다.
    보편적으로 얘기되는 속도나 보안은 의사결정에 영향을 주지만, 해당 비즈니스를 구현한 이후의 부가적인 경우입니다.
  • 163kenu
  • 2011-07-03 18:20:11
  • x
  • 제 생각으로는 성능이슈가 가장 클 듯 한데, 궁금한 것은 그렇게 DB에 비즈니스 로직을 올리게 되면 성능향상으로인한 이득이 다른 비용(유지보수비용, 이기종 DB간 멀티트랜젝션 관리비용 등)을 압도할 수 있을지가 궁금합니다.
  • 8446스쿨쥐
  • 2011-07-03 20:13:32
  • x
  • kenu 님 말씀 처럼 '의지'에 달려있습니다. 그리고 스타일에 따라 다릅니다. -_-;
    어느게 좋다라고 이야기 할 수 없고, 운영 시스템에 따라서도 다릅니다 ^^;
    만약, 자바로 구현을 한다면 지금 구현된 sp보다 효율적으로 구현이 가능한지요?
  • 7614pran
  • 2011-07-03 20:45:53
  • x
  • 개선하는 것은 좋은데 기존 설계를 따르는 것이 정신건강에 좋습니다.

    주위 사람 어필해야하고 개발하는 시간, 운영시 문제 생겼을 때의 책임등등...

    근데 한번쯤은 해볼만한 경험이라고 봅니다.
  • 1252411
  • 2011-07-04 00:01:27
  • x
  • 어느쪽이 효율적이다 성능이좋다와 같은 것을 떠나
    주석/레퍼런스 없는 2-3000라인 sql 보면, 그저 하염없이 눈물만...

    둘다 레퍼런스가 없는 환경이라면
    아무리 스파게티라도 어플리케이션쪽이 그나마 낫더군요
    제가 SQL에 약해서 그런걸까요...
  • 2587zzem77
  • 2011-07-04 01:16:00
  • x
  • SQL숙달 문제만은 아닙니다.

    주석을 아무리 깨알같이 달아도
    아무래도 계층화가 제대로 지원되지 않는 프로시져에는 논리구조적인 형태가 나오기 힘듭니다.

    그러다보니 아무래도 유지보수나 모델변경에서는 많은 소요가 따르는게 일상이죠.
  • 13497danny
  • 2011-07-04 09:39:22
  • x
  • 전에 직장에서 이렇게 한걸 본 적이 있습니다.
    모든 로직은 프로시저로 해결하고 웹 애플리케이션은 단지 조회 수준정도...

    장점은 웹 애플리케이션은 수정할 일이 거의 없다는 겁니다.
    요구사항이 수정되더라도 프로시저만 수정하면 된다는 거죠.
    게다가 예전에는 DB만을 위해 별도의 서버를 구축했기 때문에 성능이 빵빵했죠

    단점으로는 담당자 또는 전문가가 없다면 해석도 어렵다는...
    그래서 웹 개발자보다는 오라클 전문가가 더 대접 받았다는...

    개발업체 입장에서는 유지보수 때 높은 수임료를 받을 수 있다는 장점도 있네요

    보통 4-5년 지나니까 완전 재개발을 합니다.
    고객측에서도 유지보수할 인원을 구할 수가 없어서요




  • 210버드나무
  • 2011-07-04 09:40:19
  • x

  • 버드나무//님 말씀에 공감..
    모든 비지니스 로직을 PL-sql로 커버가능하다면,
    저는 이방식이 더 낫다고 생각하는데요...

    기존의 방식은 java에도 비지니스로직이 들어가고,
    java-script에도 일부 비지니스로직이 들어가고,
    쿼리에도 비지니스로직 일부 들어가고,
    뒤죽박죽...
  • 6773지나댕기
  • 2011-07-04 10:00:41
  • x
  • 네.제가 이렇게 하고 있습니다.
    역할 분담되고 유지보수 더 쉽습니다.
    쿼리 물론,프로시져 잘 다루고..
    여하튼 개발자 빠지면, 프로시져라도 잘 만들어야 하니까.
    같은사례가 SAP 도 그렇습니다.
    SAP에서 RFC 함수 만들고 UI에서 호출하는것처럼.
  • 777en92dong
  • 2011-07-04 10:19:10
  • x
  • 제가 최근 프로젝트한 경향을 보면 DB에 프로시저나 함수를 만들지 않고, 모든걸 java쪽에서 처리했습니다.
  • 2213sm&si
  • 2011-07-04 10:36:39
  • x
  • 저의 환경은 더 나아가 모드 pl/sql 이라고 해서 모든걸 다 프로시져 패키지에서 처리합니다. 심지어 자바 및 웹페이지도 pl/sql 안에 들어가 있지요 ㅠㅠㅠㅠㅠ
  • 4224크르릉
  • 2011-07-04 11:35:42
  • x
  • 자바개발자입장일수있지만 비즈니스로직이 프로시저쪽에 가는거 반대입니다..
    정말 유지보수 힘듭니다.....

    예전 플젝할때 겪어보니 그 생각은 더욱 굳건해졌구요...

    필요한 부분이 분명 필요할수있습니다..그런건 예외이구요...

  • 6150냥~
  • 2011-07-04 16:23:53
  • x
  • 자바에서 처리하는게 유지보수 측면에서 좋다고 알고있어요.
    스킬좋으신분이라면 프로시저쪽이 더 나으실수도 있지만
    유지보수를 보통 일반 개발자가 한다라고 봤을때 말이죠..
  • 10540blue0k
  • 2011-07-05 17:59:58
  • x
  • 식약청플젝이 거의 Plsql로 떡을치죠...
    반대로 삽성화재 카드같은 플젝은 아에그걸못쓰게 못박아?았죠...
    을업체의 능력에 따른 분화라고 생각합니다
  • 6810아마
  • 2011-07-07 10:13:56
  • x

 

 

 

제목 : procedure 사용과 자바 business 로직 처리의 장단점?
글쓴이: 태영(thorn) 2011/06/21 23:37:25 조회수:4640 줄수:6
프로젝트를 하다보면 업무로직 처리를 프로시저로 처리하는곳이 있습니다.
업무로직이 데이타베이스에 종속적이기때문에 다양한 서비스(재활용)를 제공하기에 운영측면에서 유연하지 못해보입니다.
선배님들의 조언 부탁드립니다.

제목 : Re: 사용을 자제하는것이...
글쓴이: alkimia(cnovice) 2011/06/22 08:12:15 조회수:4063 줄수:15
프로시져, 트리거, 함수 같은 오브젝트는 가급적 사용을 자제하는 것이 좋다고 봅니다. 
특히 비지니스 로직을 프로시져에 넣는 것은 안좋다고 생각합니다.
제가 일하고 있는 사이트(금융)도 내부적으로 프로시져, 함수에 비지니스 로직이 
상당부분 들어가 있습니다. 모하나 고칠려면 짜증납니다 ^^.
모든 마찬가지지만 프로시져도 소스 관리를 상당히 잘해야합니다. 
나중에 서로 종속적이 되서 수정할 때 문제가 생길 수도 있습니다. 
자바로 설계를 잘하면 굳이 재활용때문에 프로시져를 사용할 필요는 없다고 봅니다. 
비지니스 로직이 변경되도 굳이 소스를 고치고 싶지 않으시면 drool 같은 룰엔진을 사용하시는 것도 괜찮을듯 싶습니다.

제목 : Re: 윗분 말씀대로....
글쓴이: 손님(guest) 2011/07/07 07:33:05 조회수:3915 줄수:43
어차피 DB IO 부분은 프로시저가 아니더라도 DB에 종속적이게 됩니다. 
만약 DB 간에 마이그레이션 프로젝트에 들어간다고 하면 
어차피 DAO 부분은 고치지 않을까요? ( SQL 문법 및 기본 제공 함수 상이 등의 이유)
완전히 독립은 불가능해 보입니다. 
제가 생각하는 자바 비지니스 로직의 장점은 
1. 일단 디버깅이 쉽습니다. 
2. 소스관리가 용이합니다. 
3. DB 프로시저보다 쉽습니다(DB마다 프로시저 문법 상이). 
4. WAS의 리소스를 사용합니다. (DB의 리소스 사용을 줄여주는 것이 좋습니다.)
 4-1. 헌데 제가 큰 규모의 시스템을 못봐서 그런지 리소스 문제는 거의 발생하는걸
      보지 못했군요. 요즘 시스템을 병렬로 빵빵하게 구축하다보니.. 
단점 
1. 소스반영이 어렵다 혹은 귀찮다. ( 주로 WAS 재기동이 필요하죠 ㅋ ) 
프로시저의 장점
1. 유연하다. ( 즉시적인 반영 가능함. ) 
2. 프로그램 개발쪽이 쉬워짐. ( 인풋만 넣어서 호출하여 리턴만받아서 사용하면됨.)
3. DB 리소스가 여유가 많을 경우 프로시저 사용이 더 빠름. 
    - WAS <-> DB간 NET IO가 시간을 많이 잡아먹죵...
4. 보안적으로도 좋음.
단점
1. DB에 엄청나게 종속적이게 됨. ( 마이그하기라도 하면 힘듬. )
2. 형상관리가 어려움.
3. 디버깅 어려움.
저는 두가지 방법으로 다 개발해봤는데 프로시저 쪽이 편하더군요. 
프로시저로 개발되있으면 소스반영땜에 야간에 야근 안해도 됩니다. ㅋㅋ
즉시 반영 가능, 즉시 수정 가능입니다. 해당 업무 로직이 담겨있는 프로시저만
변경해주면 되니까요. 
로그성 테이블에 기록하기도 편하고... DAO 개발하는쪽도 DB 호출여러번
안하게 해도 되고... 헌데... DB 변경될 상황에 처하면 짜증난다는거... ㅋㅋㅋ
허접한 개발자의 경험담입니다...

제목 : Re: 프로시져 비추합니다.
글쓴이: 손님(guest) 2011/07/20 13:56:07 조회수:3762 줄수:3
procedure의 가장 큰 문제는 소스 관리 및 동시 수정에 대한 이슈죠. 
생각보다 큰 문제입니다.

제목 : Re: 프로시져 편하더군요
글쓴이: 이영래(passwd) 2013/03/12 14:04:51 조회수:4510 줄수:19
거진 10년 정도 자바로 개발로 개발하면서 자바가 제일 쉬운 언어인줄 알았습니다. 
필요한것은 거진 만들어 져 있으니까요
그런데 프로시져로 처음 개발하는데 따로 공부 많이 안해도 개발이 가능하고 
개발하자마자 반영되는 그 간편함이란... 
그런데 왜 프로시져가 많은 개발자들의 반감을 가지고 있을까? 
1. 개발 즉시 반영 -> 실수 또는 문제 발생 가능성 높음 .
2. 소스 이력 관리 어려움 -> 누가 언제 무엇을 고쳤는지 관리의 어려움. 
3. 디버깅 어려움. 
4. 모든 프로그램 영역을 커버 하기가 어려움. 
5. 모듈화가 어려워 재사용(package로 하면 되지만...) 그리고 구조화 패턴화가 어렵고 
   이렇게 모듈화 한 경우 디버깅은 더 어려워 짐. 
그래도 그 간편함과 속도는 이 모든것을 무시하게 되더군요 ^^

제목 : Re: 간편함과 속도가 형상관리의 어려움을 무시할정도는 아니던데요.
글쓴이: 손님(guest) 2013/05/09 23:27:12 조회수:3178 줄수:3
위에분.. 뭐가 얼마나 편하다고 형상관리의 어려움을 무시하고도 좋다고 하는지.. 
당황스런 상황을 경험해봐야 알겠지요.

 

 

저작자표시 비영리 변경금지

'정보과학 IT' 카테고리의 다른 글

Oracle Pro*C, MSVC++ 환경설정 (◀pcscfg.cfg 설정 포함)  (0) 2013.11.22
MSVC++ 를 사용하여 PRO*C PROJECT 를 만드는 방법   (0) 2013.11.22
(PROC) DATABASE CONNECTION  (0) 2013.11.21
(MSVC++) mspdb100.dll 오류와 vcvars32.bat  (0) 2013.11.20
Visual C++ installed, but cannot find cl.exe?  (0) 2013.11.19

'정보과학 IT'의 다른글

  • 현재글Business Logic(비즈니스 로직) - DB or App ..

관련글

티스토리툴바