Curixsoft 2013-02

질문에 대한 답은 아니지만
Trigger를 쓰면 dbms에서 많은 자원을 쓰게됩니다
Disk i/o 또한 상당히 점유를합니다.
특수상황이 아니라면
해당 기능을하는 간단한 트렌잭션 프로그램을 만들어 쓰시는걸
 추천 드립니다.
업무시스템어 적용하시려는 것 같은데 만드신 프로그램을
해당 프레임웍에 맞게 포팅시키고,업무 트렌잭션보다
먼저 호출되는 형식을 취하면 되겠습니다

서버유져 2013-02

답글 감사합니다~

어떻게 하는지 모르겠지만

한번 찾아서 시도해봐야겠네요 ^^

회원K 2013-02

유지보수 차원에서 트리거는 추천하지 않습니다.
MySQL의 경우 mysqli가 mutil SQL도 지원 합니다.
그냥 프로그램에 넣는 것이 더 좋습니다.

딸기대장 2013-02

개인적인 느낌인데...
트리거를 사용하시든, 프로그램을 사용하시든... 한쪽으로 몰아야 됩니다. ^^
job도 아닌데...실제로 트리거로 프로그램한 적은 거의 없는 것 같네요.

Curixsoft 2013-02

가장 쉽게 설명드린다면,

많은 분들이 알고 계시는 Select(selection) 명령 처리시
dbms의 엔진이 명령을 해석하고,
시스템에 실행가능한 명령으로 재구성하게됩니다.
이시간을 줄이려고하는 것이 튜닝분야이죠.

튜닝은 disk i/o 줄이는 곳에도 존재하구요.

또한 실행된 결과를 메모리(Main memory와 Vitural memory)에 나르는 작업합니다.

제가 생각하는 dbms의 성능은 바로 저 결과를 나르고 memory에 탑재하는 과정의 퍼포먼스라고
생각합니다.

탑재된 데이터는 dbms의 시스템 인터페이스중 출력부에 전송되어, 실제 명령을 수행한 유저한테
보이게됩니다.

여기서 결과를 만들어내고 메모리에 탑제되기까지 수많은 disk i/o가 발생합니다.

일반적인 명령의 경우입니다.


여기서 trigger가 있다면 dbms(일부는 OS라고도 부르기도합니다)의 명령을 해석하는 곳에서
 끊임없이 trigger의 존재를 파악하고, 해당하는 trigger script를 수행하려고 시도합니다.

반복적인 이런 탐색과 명령해석, 실행까지 많은 자원을 낭비하게되고 다중커넥션이 존재하는 dbms의
경우에는 퍼포먼스의 향상을 위해서는 management가 배제되며, H/W upgrade라는 단한가지의
방안밖에 선택할수 없습니다.

더욱 우려스러운 경우라면

스트림형식의 대용량 데이터의 다중처리시 시스템이 비정상적으로 되기도 합니다.
(여러곳에서 전송되는 대용량전문 입력이 되는 시스템에서 dbms로의 데이터이관시)

일반적으로 서버가 죽었다고 합니다.

그래서 개발문서나 개발규칙, dbms운영 메뉴에 자주 등장하는 대목이기도 합니다.

도움이 되었을런지, 제가 아는 짧은 지식이나마 이렇게 전해드립니다.

이상입니다.