이런경우는 트리거에서 처리를 하는 것이 맞습니다.
한가지 더 들자면 데이터의 Tranaction 양이 많지 않다면 트리거에서 Update , Insert , Delete에 대한 모든 내용을
같은 모양새의 테이블을 만드시고 나머지 정보를 넣어 주시면 됩니다. 이 테이블은 백업용 이고 실제로 연동 되어야 하는 부분에 대한 트리거도 같이 포함 하셔야 겠지요. 여기서 함정이 하나 있는데 데이터의 변경 내용중 사용자 정보가 들어가야 한다면 트리거가 아닌 프로시저로 합니다.
예를 들자면 이거지요 아무개 사용자가 언제 무슨 자료를 변경 하였다. 이러면 컬럼이 3가지가 추가가 되나 트리거에서는 그 정보를 받아다 넣기가 곤란 합니다. 이런 경우는 차라리 프로시저로 처리 합니다.
프로시저로 처리 한다는 말은 프로그램에서 직접 처리 해야 한다(직접 호출)고 보시면 되고 이건 프로그램 소스 수정이 불가피 합니다.
다만 단순 변경 부분을 직접 적용 해도 상관 없다면 링크 서버를 이용하여 트리거로 처리 합니다.
안그러면 인터페이스가 따로 필요 하게 처리하는것이 필요하나 역시 소스 수정 및 컬럼 추가 없이는 테이블 전체 검색 하기 때문에 업무에 지장을 초래 할 수도 있습니다. 결국은 트리거나 프로시저가 더 적절 하다고 할 수 있습니다.
그냥 프로그램단에서 양쪽에 다 수정하는건 안 되나요??
현장에서 트리거를 별로 안 좋아 하는 이유는
버그 트레킹이 힘들어서 입니다.
A db의 테이블이 단독으로 입력/수정/삭제 가 없다면 view도 고려 대상에 넣으시면 됩니다.
한가지 더 들자면 데이터의 Tranaction 양이 많지 않다면 트리거에서 Update , Insert , Delete에 대한 모든 내용을
같은 모양새의 테이블을 만드시고 나머지 정보를 넣어 주시면 됩니다. 이 테이블은 백업용 이고 실제로 연동 되어야 하는 부분에 대한 트리거도 같이 포함 하셔야 겠지요. 여기서 함정이 하나 있는데 데이터의 변경 내용중 사용자 정보가 들어가야 한다면 트리거가 아닌 프로시저로 합니다.
예를 들자면 이거지요 아무개 사용자가 언제 무슨 자료를 변경 하였다. 이러면 컬럼이 3가지가 추가가 되나 트리거에서는 그 정보를 받아다 넣기가 곤란 합니다. 이런 경우는 차라리 프로시저로 처리 합니다.
프로시저로 처리 한다는 말은 프로그램에서 직접 처리 해야 한다(직접 호출)고 보시면 되고 이건 프로그램 소스 수정이 불가피 합니다.
다만 단순 변경 부분을 직접 적용 해도 상관 없다면 링크 서버를 이용하여 트리거로 처리 합니다.
안그러면 인터페이스가 따로 필요 하게 처리하는것이 필요하나 역시 소스 수정 및 컬럼 추가 없이는 테이블 전체 검색 하기 때문에 업무에 지장을 초래 할 수도 있습니다. 결국은 트리거나 프로시저가 더 적절 하다고 할 수 있습니다.