관리적 측면에서 분명 procedure나 trigger가 불리한 점이 있지만..

JAVA내에서 처리하게 되면 DB Call이 그만큼 많이 늘어나게 되어는 측면이 있죠.

반대로 자바단에서 처리하면 DB쪽 CPU 사용율이라든지 메모리 사용률은 좀

떨어지지 않을까 하는 추측도 되구요.

JAVA에서 처리할 때 얻는 이점이 DB Call에 소모되는 실보다 크다면 JAVA단에서

처리해주면 좋을 것이고 그게 아니라면 procedure로 처리하는 방법도 저는

나쁘지 않다고 생각합니다.

예를들어 병원 수납 로직의 경우에 수납을 위한 procedure 라인 수만 해도 엄청나요.

측정해보지 않았지만 몇 만라인 될 거라 예상합니다.

해서 db call도 무수히 많이 일어납니다. 이런 로직은 제 생각에는

procedure로 만들어 주는 게 좋을 거예요. db call도 줄어들 뿐만 아니라

수납자가 많아봤자 3~40명 정도라면 cpu 사용율도 크게 올라가지 않을 것 같구요.

JAVA단으로 만든다면 성능적으로 조금 떨어지지 않을까 생각합니다.

반대로 로직단에서 파일을 사용자에게 리턴한다든지.. procedure로 하기 어려운

부분이 있다면 JAVA단이 유리하겠죠.

트리거의 경우에도 데이터 정합성을 지켜주는 측면에서 분명한 장점이 있습니다.

JAVA단에서 아무리 꼼꼼하게 로직을 만들어놓아도 언젠가 구멍이 날 수 있죠.

그런데 DBA분들은 procedure, trigger 싫어하시죠ㅎㅎ

procedure, trigger을 원칙적으로 쓰지 못하게 하는 곳도 있고요.

결론은 진리의 케바케..;

저도 관리 측면이 제일 문제라고 생각합니다.

Trigger, Procedure 소스 형상관리를 새벽에 일배치로 소스로 내린다음

subversion에 커밋하는 방법을 쓰고 있는데, 하루 내에서의 변경 사항은 관리할수도 없을뿐더러

누가 변경했는지도 알기 어렵고, DB 접근 권한만 있으면 누구나 변경 가능하다는것도 문제입니다.

무엇보다 테스팅 자동화가 쉽지 않네요

저도 버전관리라든지 이런 점 때문에 프로시저가 좀 골치 아프더라구요.

daily backup을 만들어 놓았지만 누가 변경했는지는 로그가 안 남기도 하구요.

요즘은 보안 정책 때문에 개발자별로 계정이 주어지고 주어진 권한만 실행할 수

있도록 많이들 하더라구요. 권한 관리 측면에서 많이 번거롭죠.ㅎㅎ

개발자별로 무슨 작업했는지 로그도 남기고 프로시저 빌드의 경우 자동으로

이전 버전 백업되게 해주는 서드파티툴 같은 거 있으면 괜찮을 거 같긴한데..

이미 있을지도 모르겠네요.