9

シナリオ：

データがテーブルに挿入/更新/削除されるたびに、最大 3 つのことが発生する必要があります。

  1. データは別のテーブルに記録する必要があります
  2. 参照整合性は、暗黙的な関連データに適用する必要があります (外部キー関係にリンクする必要があるデータを参照していますが、そうではありません: たとえば、更新Table1.NameもTable2.Name同じ値に更新する必要がある場合)
  3. 任意のビジネス ロジックを実行する必要がある

データベースのアーキテクチャとスキーマを変更してはならず、要件はトリガーを使用して達成する必要があります。

質問

どちらのオプションが優れていますか?:

  1. 操作 (挿入/更新/削除) ごとに 1 つのトリガーで、複数の問題 (ログ、暗黙的な参照整合性の適用、および任意のビジネス ロジックの実行) を処理します。このトリガーには名前を付けることができますD_TableName(削除の「D」)。

  2. 懸念によって分離された操作ごとの複数のトリガー。それらは次のように命名できます。

    • D_TableName_Logging-何かが削除されたときのログ用
    • D_TableName_RI
    • D_TableName_BL

私はオプション 2 を好みます。コードの 1 つのユニットには 1 つの関心事があるからです。私は DBA ではありませんが、危険にさらされるほど SQL Server について十分に知っています。

1 つのトリガーですべての懸念事項を処理する説得力のある理由はありますか?

4

4 に答える 4

4

うわー、あなたは勝てない状況にあります。トリガーを介してこれらすべてを実行するように要求した人は、撃たれてから発砲する必要があります。トリガーを介して RI を適用しますか?

データベースのアーキテクチャとスキーマを変更してはいけないとおっしゃいました。ただし、トリガーを作成すると、少なくともデータベースのスキーマが変更され、アーキテクチャが変更される可能性があります。

おそらくオプション #1 を使用し、ロギング、BL、および RI を処理する追加のストアド プロシージャと UDF を作成して、個々のトリガー間でコードが重複しないようにします (トリガーはこれらのストアド プロシージャおよび/または UDF を呼び出します)。オプション2で提案した方法でトリガーに名前を付けるのは本当に好きではありません。

ところで、あなたの組織の誰かに、これは正気ではないことを伝えてください。RI はトリガーを介して強制されるべきではなく、ビジネス ロジックはデータベースに属しません。

于 2013-01-03T19:11:10.030 に答える
4

すべてを 1 つのトリガーで実行すると、(インデックスが作成されていない)insertedおよびdeletedテーブルに対する操作が少なくなる可能性があるという点で、より効率的になる可能性があります。

また、複数のトリガーがある場合、起動する最初と最後のトリガーを設定することは可能ですが、他のトリガーは任意の順序で起動するため、特定のアクションに 3 つ以上のトリガーがある場合、イベントのシーケンスを決定論的に制御することはできません。

これらの考慮事項のどちらにも当てはまらない場合は、単なる好みの問題です。

もちろん、トリガーでこれを行う仕様が最悪であることは言うまでもありません。

于 2013-01-03T19:11:35.503 に答える
2

@RandyMinderに同意します。しかし、私はさらに一歩進みます。トリガーは、この状況にアプローチする正しい方法ではありません。あなたが説明するロジックは、トリガーメカニズムには複雑すぎます。

ストアド プロシージャで挿入/更新/削除をラップする必要があります。これらのストアド プロシージャは、ビジネス ロジックやログなどを管理できます。また、彼らは何が起こっているのかを明らかにします。ストアド プロシージャを呼び出す一連のストアド プロシージャは明示的です。トリガーを呼び出す一連のトリガーは、トリガーへの呼び出しを明示的にしない挿入/更新/削除ステートメントによって決定されます。

トリガーの問題は、異なるテーブル間で依存関係とロックが発生することであり、依存関係を解きほぐすのは悪夢になる可能性があります。同様に、問題がトリガーを呼び出すトリガーにある場合、パフォーマンスのボトルネックを特定するのは悪夢です。トリガーを呼び出すストアド プロシージャを呼び出します。

于 2013-01-03T19:17:52.493 に答える