回答。

ストアドプロシージャ (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 トリガーの実行順序を保証しません。順序が重要な場合は、1つに統合する必要があります。

このトピックの微妙さを知らないことによる実際のエラーの例。

---

物語

CRMソリューションで変更履歴の機能をサポートするためにトリガーを使用しました。大量の更新による高負荷のため、ログへの記録が遅延し、「本番」操作がブロックされ、サービスが一時的に利用できなくなりました。

---

物語

開発者は、ストアドプロシージャではなくトリガーでデータ検証のロジックを作成し、ユーザーがすぐに変更に気づくことを期待しました。トリガーが「透過的」であることを忘れ、ビジネスロジックが不明確（「魔法」）になり、デバッグが難しくなる問題に直面しました。

---

物語

重要: ストアドプロシージャ内でトリガーを呼び出すか、トリガー内からストアドプロシージャを呼び出すことがよくあり、これにより再帰的な呼び出しや入れ子の制限を超えることになります。たとえば、自動挿入が関連するプロシージャを介してトリガーを再び起動します。