8


1

私はテーブルの挿入/更新/削除操作を実行するストアドプロシージャを持っているとします。

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

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

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

これら2つのテーブルは* Inserted deleted *が存在する(永続的)か、それとも動的に作成されますか。

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

それらが永続テーブルの場合、どこにあるのでしょうか。

またそれらがexixtsなら私はストアドプロシージャの* Inserted Deleted *テーブルにアクセスできますか?

4 Answer


7


はい、トリガを持つテーブルは、それがないとパフォーマンスが向上しません。 ロジックは、何かをすることは何もしないことよりも費用がかかることを示しています。

あなたが指定していない他の方法よりもパフォーマンスが高いかどうかという点であなたが尋ねたなら、あなたの質問はもっと意味があると思います。

究極的には、私はその仕事に最も適したツールを選択し、問題がある場合はパフォーマンスを心配するだけで、あなたが解決策を実装する前でさえないでしょう。

挿入されたテーブルと削除されたテーブルはトリガー内で使用可能であるため、ストアード・プロシージャーからそれらを呼び出すのは簡単ではありません。


7


ストアドプロシージャで同じことをするよりもパフォーマンスが劣るでしょうか。 たぶんすべてのパフォーマンスの問題で本当に知る唯一の方法は現実的なデータセットで両方のアプローチをテストすることです(あなたが2,000,000レコードテーブルを持っているならば100レコードのテーブルでテストしないでください!)

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

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

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


2


定義上、クエリのパフォーマンスが低下します。それ以外の場合は実行されませんでした。

もう1つの見方は、これです。トリガーが何をしているのかを手動でやろうとしているのであれば、ラウンドトリップを節約することでパフォーマンスを向上させます。

さらに一歩踏み込んでください。ストアドプロシージャを使用していて、いずれにしても1つのサーバーラウンドトリップ内で実行している場合は、この利点はなくなります。

だからそれはあなたがそれをどう見ているかにかかっている。


0


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

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