SQL 트리거 및 사용시기 및 사용시기

원래 SQL에 대해 배웠을 때 항상 들었습니다. 실제로 필요한 경우 저장 프로 시저를 대신 사용해야하는 경우에만 트리거를 사용하십시오.

불행히도 당시 (몇 년 전) 나는 기본에 대해 호기심이 많지 않았고 지금은 그 이유를 묻지 않았습니다.

이것에 대한 커뮤니티 의견은 무엇입니까? 정당한 사유가없는 한 누군가의 개인적 취향 일까, 아니면 커서와 같은 방아쇠를 피해야 하는가?

데이터베이스 트리거에 대한 Wikipedia 기사는 트리거가 무엇이며 언제 다른 데이터베이스에서 트리거를 사용해야하는지에 대한 좋은 개요를 제공합니다.

다음 설명은 SQL Server만을 기반으로합니다.

트리거 사용은 정당화 될 때 매우 유효합니다. 예를 들어, 모든 테이블의 모든 CRUD 명령과 함께 명시적인 절차 코드를 요구하지 않고 감사 (데이터 기록 유지)에 가치가 있습니다.

트리거를 사용하면 데이터가 변경되기 직전과 데이터가 변경된 직후에 제어 할 수 있습니다. 이를 통해 다음이 가능합니다.

• 앞에서 언급 한 감사
• 원하는 경우 유효성 검사 및 비즈니스 보안 검사. 이 유형의 제어로 인해 데이터베이스에 삽입하기 전후에 열 형식화와 같은 태스크를 수행 할 수 있습니다.

나는 항상 당신이 정말로 필요한 경우에만 저장 프로 시저를 사용하도록 선택하고 트리거를 사용한다고 들었습니다.

이에 대한 몇 가지 이유는 다음과 같습니다.

1. 예전에는 트리거를 사용한 일부 기능을 총계 업데이트 및 열 자동 계산과 같은 다른 방식으로 수행 할 수있었습니다.
2. 코드의 존재 여부를 모르고 코드 만 검사하여 트리거가 호출 된 위치를 알 수 없습니다. 데이터 변경 사항을 볼 때 그 효과를 볼 수 있으며, 테이블에 트리거가 있거나 더 많은 행동이 있다는 것을 알지 못하면 변경이 발생한 이유를 파악하기가 때로는 수수께끼입니다.
3. 여러 테이블에서 CHECK, RI, 트리거와 같은 여러 데이터베이스 컨트롤을 사용하면 트랜잭션 세부 흐름을 이해하고 유지하기가 복잡해집니다. 언제 어떻게되는지 정확히 알아야합니다. 다시, 당신은 이것에 대한 좋은 문서가 필요합니다.

트리거와 비 트리거 저장 프로 시저의 차이점은 다음과 같습니다.

• 트리거가 아닌 저장 프로시 저는 코드 나 스케줄러 또는 배치 작업 등에서 작업을 수행하기 위해 명시 적으로 호출해야하는 프로그램과 비슷하지만, 트리거는 사용자가 직접 실행하지 않고 이벤트 응답 이벤트는 예를 들어 데이터 열의 데이터 변경 일 수 있습니다.
• 트리거에는 유형이 있습니다. DDL 트리거 및 DML 트리거 (유형 : INSTEAD OF, For 및 AFTER)
• 비 트리거 저장 프로시 저는 모든 유형의 개체를 참조 할 수 있지만 뷰를 참조하려면 INSTEAD OF 트리거를 사용해야합니다.
• SQLServer에서는 트리거가 아닌 스토어드 프로 시저에 대해 임의의 수를 지정할 수 있지만 테이블 당 하나의 INSTEAD OF 트리거 만 있습니다.

트리거는 복잡한 데이터 무결성 규칙에 대한 요구 사항입니다. 데이터베이스 이외의 다른 곳에서는 적용 할 수 없거나 데이터 무결성 문제가 있습니다.

또한 데이터베이스에 대한 모든 변경 사항을 캡처하지 않으려는 경우 (애플리케이션의 감사 문제) 감사를위한 최적의 장소입니다.

주의 깊게 작성하지 않으면 트리거가 성능 문제를 일으킬 수 있으며 충분한 개발자가 잘 작성하지 못할 수 있습니다. 이것은 그들이 나쁜 랩을 얻는 곳의 일부입니다.

트리거는 종종 데이터 무결성을 유지하는 다른 방법보다 느리므로 검사 제한 조건을 사용할 수있는 경우 트리거 대신 트리거를 사용하십시오.

이메일 보내기와 같은 어리석은 일을하는 나쁜 방아쇠를 작성하는 것은 쉽습니다. 이메일 서버가 다운되면 DB에서 레코드를 변경할 수 없도록 정말로 하시겠습니까?

SQL Server에서 트리거는 일련의 레코드에서 작동합니다. 너무 자주 개발자는 하나의 레코드 삽입, 업데이트 또는 삭제 만 처리하면된다고 생각합니다. 이는 데이터베이스에 발생하는 유일한 종류의 데이터 변경이 아니며 모든 트리거는 1 레코드 변경 및 많은 레코드 변경 조건에서 테스트되어야합니다. 두 번째 테스트를 잊어 버리면 트리거 성능이 크게 저하되거나 데이터 무결성이 손실 될 수 있습니다.

데이터베이스 트리거 사용

1. 열 값을 자동으로 구동합니다.
2. 복잡한 무결성 제약을 강화합니다.
3. 복잡한 비즈니스 규칙을 시행합니다.
4. 복잡한 보안 인증을 사용자 정의합니다.
5. 복제 테이블을 유지 보수합니다.
6. 데이터 수정을 감사합니다.

개인적으로 접한 또 다른 유스 케이스는 둘 이상의 프로그램에서 액세스하는 데이터베이스입니다. 기능을 구현하고 싶지만 모든 시스템을 재 설계하지 않으려는 경우 트리거가 합리적인 솔루션입니다.

예를 들어, 나는 최근에 사무실 시스템으로 만 존재했던 데이터베이스를 작업했습니다. 웹앱이 웹 인터페이스와 인터페이스하도록 작성되었을 때 트랜잭션 처리 등과 같은 여러 이벤트에 의해 발생하는 알림 시스템 (예 : 스택 교환과 유사)을 구현하려고했습니다. 우리는 사무실 백엔드의 업데이트가 트리거를 발생시켜 프론트 엔드에 대한 알림을 작성하고 사용자가 자신의 거래가 사무실에 의해 처리되었음을 알리도록 트리거를 구현할 수있었습니다.

트리거는 데이터베이스 스키마 작성 및 DML 문 중에 시행 할 수없는 데이터베이스에 대한 제한 조건을 적용하는 데 사용할 수 있습니다.

거의 실시간으로 타사 시스템에 데이터를 푸시해야한다고 가정 해 보겠습니다. 테이블에 950 기가 바이트의 데이터가 포함되어 있으므로 전체 테이블을 타사 앱으로 푸시하기에는 너무 큽니다.

대신 대기열에 변경 사항이 누적됩니다. 그런 다음 일부 외부 프로그램은 주기적으로 소량의 대기중인 데이터를 밀어냅니다.

이 시스템에는 2000 개가 넘는 저장 프로 시저가 있습니다. 또한 소스 코드에 수많은 SQL이 존재한다는 것도 알고 있습니다. 대기열이 올바르게 채워지도록하려면 저장된 모든 proc와 코드를 검색해야하며 아무것도 놓치지 않기를 바랍니다.

대신 큐를 업데이트 된 상태로 유지하기 위해 테이블에 트리거를 둘 수 있습니다. 아무것도 놓치지 않도록 보장했습니다. 하나의 중심 위치. 페널티? 트리거에 의한 것이 든 외부적인 것이 든 큐를 채우는 히트를 피할 수 없기 때문에 실제로는 아닙니다.

이 시나리오에서는 트리거를 사용하지 않는 것이 나쁜 설계 선택이라고 말합니다. 나중에 새로운 데이터 푸시 방법 (대기열이 작동하지 않음)을 사용하려는 경우 트리거를 사용하면 인터페이스 변경이 보호됩니다. 트리거가 종종 최선의 선택입니다. 독단적 트리거 방지 팬보이를 듣지 마십시오.

이메일을 보내는 트리거가 반드시 '멍청한'아이디어는 아닙니다. 어리석은 것은 설계에서 이메일 중단을 예상하지 않고 데이터 손실없이 정상적으로 처리하는 것입니다. 이것의 '어리석은'부분은 실수를 저지르는 것으로 느낀 게으른 개발자가 존재하지 않는 오류 처리에 실제로 나쁩니다.

또한 임의적으로 복잡하고 여러 트리거 또는 다른 저장 프로 시저에서 재사용 할 수있는 저장 프로 시저 / 함수를 호출하여 트리거를 간단하게 유지할 수 있다는 관찰 결과를 제공합니다. 그렇기 때문에 패키지와 라이브러리가 있습니다.

편견은 정말 무섭습니다.