トリガーはパフォーマンスを低下させますか？挿入されたテーブルと削除されたテーブル

Question

テーブルに挿入/更新/削除操作を実行するストアドプロシージャがあるとします。

いくつかの基準に応じて、いくつかの操作を実行したいと考えています。

トリガを作成するか、ストアドプロシージャ自体で操作する必要があります。

トリガーを使用するとパフォーマンスが低下しますか？

挿入とすなわち、これらの2つの表は、が存在している（永続的）または動的に作成され、削除していますか？

動的に作成された場合、パフォーマンスに問題があります。

永続表の場合はどこにありますか？

また、彼らはその後、exixts私はがを挿入しは、ストアド・プロシージャでテーブルを削除したアクセスすることができますか？

Answer 1

パフォーマンスは何ですか？トリガーはイベントの後にDB上で更新を実行するので、システムのユーザーはそれが起こっていることさえ知りません。それはバックグラウンドで起こります。

あなたの質問は非常に理解しづらい方法で表現されています。

Answer 2

はい、トリガーのあるテーブルは、それがないと同様に機能しません。ロジックは何かをすることは何もしないよりも高価だと指示します。

あなたが指定していない他のアプローチよりもパフォーマンスが優れているかどうかを質問すると、あなたの質問はより意味があると思います。

最終的には、ジョブに最も適したツールを選択して、ソリューションが実装される前であっても、問題が発生した場合のみパフォーマンスが心配されます。

挿入されたテーブルと削除されたテーブルは、トリガ内で使用できるため、ストアドプロシージャから呼び出すことはできません。

Answer 3

これは、定義によってクエリのパフォーマンスが低下します。クエリは、そうでない場合は実行しないことを実行しています。

これを見るもう1つの方法は次のとおりです。トリガーが何らかの方法で手動で行う場合は、ラウンドトリップを保存してパフォーマンスを向上させます。

さらに進んでください：ストアドプロシージャを使用していて、とにかく1つのサーバーラウンドトリップ内で実行していると、その利点はなくなります。

だから、あなたの見方によって異なります。

Answer 4

ストアドプロシージャで同じことを行うよりパフォーマンスが低下しますか。おそらくすべてのパフォーマンスに関する質問では、本当に知る唯一の方法は、現実的なデータセットで両方のアプローチをテストすることです（100万レコードのテーブルで200万レコードテーブルをテストしない場合！）

つまり、トリガーと別の方法の選択は、データがどのように更新、削除、挿入されても問題のアクションが発生する必要性に完全に依存します。これが何に関係なくいつも起こらなければならないビジネスルールであれば、トリガーが最適な場所です。そうしないと、最終的にデータの完全性の問題が発生します。データベース内のデータは、GUI以外のソースから頻繁に変更されます。

トリガーを作成する際には、注意すべき点がいくつかあります。最初に、トリガーは各バッチに対して1回だけ起動します。したがって、1つのレコードを挿入した場合でも10万レコードを挿入した場合でも、トリガーは1回だけ起動します。 1つのレコードだけが影響を受けると想定することはできません。また、それは常に小さなレコードセットに過ぎないと想定することもできません。このため、100万行を挿入、更新、または削除する場合と同様に、すべてのトリガーを記述することが重要です。これは、セットベースのロジックを意味し、可能であればカーソルもループもありません。 1つのレコードを処理するために書き込まれたストアドプロシージャをトリガー内のカーソルで呼び出さないでください。

また、カーソルから電子メールを送信しないで、電子メールサーバーが停止している場合は、すべての挿入、更新、または削除を停止する必要はありません。