ASP.NETコードビハインドを使用してデータベースにアクセスしてクエリを実行する場合と、SQLストアドプロシージャを使用する場合のパフォーマンスの違いは何ですか?
使いやすさのために、特にメンテナンスや変更の際に、クエリのコーディングが簡単になります。
ただし、ストアド プロシージャはデータベースでコンパイルされ、データベースによって実行されます。
どちらがより効率的で使いやすいですか?
ASP.NETコードビハインドを使用してデータベースにアクセスしてクエリを実行する場合と、SQLストアドプロシージャを使用する場合のパフォーマンスの違いは何ですか?
使いやすさのために、特にメンテナンスや変更の際に、クエリのコーディングが簡単になります。
ただし、ストアド プロシージャはデータベースでコンパイルされ、データベースによって実行されます。
どちらがより効率的で使いやすいですか?
SQL Serverは、SPROCであるかどうかに関係なく、クエリの実行プランをキャッシュします。ここでは実質的に違いはありません。基本的に、sprocを使用する場合は、ネットワーク経由でクエリテキストを送信する手間を省くことができます。ソース: http: //msdn.microsoft.com/en-us/library/ms181055.aspx
特別な理由がない場合は、自分にとって都合のよいことをしてください。
sprocのパフォーマンスが一般的に優れていることを示唆する他の回答は正しくありません。
データベース中心のクエリである限り、ほとんどの場合、ストアドプロシージャの方が高速です(パフォーマンス)。
ただし、通常のソースバンドルに含まれていないため、保守が困難です。
「より良い使用」は要件によって異なります。クエリが少し遅い場合(1ミリ秒対3ミリ秒など)に問題がない場合は、コードをまとめてASPに配置します。パフォーマンスが必要な場合は、データベースに入れてください。
私はほとんどのクエリをコードに入れ、データベースでパフォーマンスを必要とするものだけを入れました。
もちろん、使用するデータベースシステムにもよります。
あなたの質問は、あなたが実際に比較しているものに関して非常に不完全です。
SQL コードがストアド プロシージャにあるか、クライアントから送信された本格的なインライン SQL ステートメントにあるかは、通常、パフォーマンスにほとんど違いはありません (適切なパラメーター化と SQL が非病理的であると仮定します)。プロシージャの実行権ではなく、ベース テーブルまたはビューに付与する必要があるセキュリティ アーキテクチャとアクセスに大きな違いが生じる可能性があります。ストアド プロシージャは要件としてパラメータ化を推奨しますが、インライン SQL でもパラメータ化が可能です。
データベースから返されたセットに対してロジックを実行することと、データベースで作業を行うことについて話している場合、これは両方の方法で行うことができます。操作の種類、インデックス作成の種類、クライアントとデータベース間の帯域幅、および要求の数によって異なります。サービスを受ける必要がありました。
通常、結合/ループ ロジックをクライアントから抽象化し、ネットワーク上のデータ (列と行の両方) を削減し、シンプルなデータ セット API をクライアントに提示するために、まずデータベースでそれを行うことを検討しますが、それは依存します.