답변.

저장 프로시저 (stored procedures) — 명시적으로 호출되며 매개변수를 받아들일 수 있는 프로그래밍 블록으로, 복잡한 비즈니스 로직과 트랜잭션 처리를 수행하고, 데이터 세트나 출력 매개변수를 반환할 수 있습니다.

트리거 (triggers) — 데이터 변경 이벤트 (INSERT, UPDATE, DELETE)에 "자동으로" 작동하는 특별한 객체로, 테이블에 대한 특정 작업이 있을 때 지정된 로직을 투명하게 수행합니다.

프로시저 사용 시기

• 대량 데이터 처리 필요 시.
• 트랜잭션에 대한 명확한 제어가 필요한 경우.
• 결과나 여러 데이터 세트를 반환해야 할 경우.

트리거 사용 시기

• 데이터 변경 시 암시적 검증이나 업데이트를 보장해야 할 경우 (예: 감사).
• 완전성 검사를 구현해야 할 경우.

코드 예제

저장 프로시저:

CREATE PROCEDURE UpdateProductPrice
  @ProductID int, @NewPrice money
AS
BEGIN
  UPDATE Products SET Price = @NewPrice WHERE ProductID = @ProductID;
END

트리거:

CREATE TRIGGER trg_ProductsPriceChange
ON Products
AFTER UPDATE
AS
BEGIN
  INSERT INTO PriceAuditLog(ProductID, OldPrice, NewPrice, ChangeDate)
  SELECT i.ProductID, d.Price, i.Price, GETDATE()
  FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID
  WHERE i.Price <> d.Price
END

트릭 질문.

Q: SQL Server에서 동일한 테이블에 대해 여러 AFTER 트리거의 실행 순서를 표준 방법으로 정의할 수 있나요?

A: 아니요, SQL 표준은 동일한 테이블의 동일한 유형의 AFTER 트리거의 실행 순서를 보장하지 않습니다. 순서가 중요하다면, 하나로 결합해야 합니다.

주제의 세부 사항을 모름으로 인한 실제 오류 사례.

---

이야기

CRM 솔루션에서 변경 이력 기능을 지원하기 위해 트리거를 사용했습니다. 대량 업데이트의 높은 부하로 인해 로그에 기록되는 데 지연이 발생했고, "전투" 작업을 차단하여 서비스의 일시적인 비가용성을 초래했습니다.

---

이야기

개발자가 데이터를 확인하는 로직을 프로시저가 아닌 트리거에서 구현했으며, 사용자가 변경 사항을 즉시 볼 것으로 예상했습니다. 트리거가 "투명하다"는 사실을 잊은 그는 비즈니스 로직이 비명확해져 ("마법") 디버깅이 어려워지는 문제에 직면했습니다.

---

이야기

중요: 프로시저 내에서 트리거를 호출하거나 트리거 내에서 프로시저를 호출하여 재귀가 발생하고 최대 중첩 한계를 초과하는 경우가 종종 발생합니다. 예: 자동 삽입이 관련 프로시저를 통해 트리거를 재실행하게 합니다.