2011-02-09 51 views
0

私は検索用のWebページを開発しています。私は、パラメータ、ユーザが入力し、それをサーバーに送るに応じてページ上でクエリを作成するには、このページクエリ対ストアドプロシージャ。 2つのアプローチの違い

  1. を構築するために2つのオプションがあります。

  2. ストアドプロシージャにパラメータを送信し、そこでクエリをビルドして実行させる。

私はどのアプローチを採用すべきか、なぜそれを知りたいのですか。

両方のアプローチの長所や短所を知りたい。

+0

[アドホッククエリ対動的SQL対ストアドプロシージャ]の可能な重複(http://stackoverflow.com/questions/2934634/ad-hoc-queries-vs-stored-procedures-vs-dynamic-sql) – Earlz

+0

次のリンクからアイデアを得ることができます:http://stackoverflow.com/questions/2934634/ad-hoc-queries-vs-stored-プロシージャー - 対ダイナミック - s ql http://www.simple-talk.com/sql/t-sql-programming/to-sp-or-not-to-sp-in-sql-server/ http://www.techrepublic.com/コードでのSQL/5766837 – Brij

答えて

0

私はデータベースの専門家ではありませんが、私の経験では、ストアドプロシージャは長期間にわたって変化しない固定クエリをカプセル化するのに適しています。しかし、それを維持するのは難しいです。少なくとも、私がやっていた日に戻ってきました。ストアドプロシージャをリビジョン管理下に置いて、サーバとのrsyncのようなことをする方法がなかったからです。したがって、単一のスクリプト、またはリビジョン管理下の単一のスクリプトグループですべての必要な変更を行うことができたので、ただちにクエリを作成するのは簡単でした。おそらくこれに関して変更されたことがあり、ストアドプロシージャをコードベースとよりよく統合することができます。その場合、ストアドプロシージャによってコードをより管理しやすく保守しやすくなる可能性があります。

-1

ストアドプロシージャを使用する方が常に優れています。

1)クエリが長い場合は、ネットワークリソースを消費します。ネットワーク接続を介して大規模なSQLクエリを送信すると、ネットワークトラフィックが増加します。

2)ストアドプロシージャはあらかじめコンパイルされ格納されているため、処理が高速です。

3)クエリを変更するときにも管理が簡単です。

+3

の1つの場合、true;アドホッククエリが解析され、クエリプランが決定されると、そのクエリプランはキャッシュされ、再利用され、そのアドホッククエリへのその後の呼び出しは**高速です**ストアドプロシージャを呼び出すとき –

+1

1)クエリは、これをファクタにするためにはかなり面倒です。 2)それは神話です(http://www.scarydba.com/2009/09/30/pre-compiled-stored-procedures-fact-or-myth/)。 3)それは非常に主観的です。 – JohnFx

0

ストアドプロシージャを使用します。彼らは高速ですが、データベースとの契約を強制するため(ストアドプロシージャにこれらのパラメータを渡してデータを返すため)

UIで表示するような、データの処理方法をアプリケーションに決定させます。ストアドプロシージャがデータの挿入/更新/削除/取得の方法を決定するようにします。

ストアドプロシージャのクエリ/ロジックを複数のフロントエンドに再利用する方がずっと簡単です。

0

フロントエンドからクエリを渡すことにより、SQLインジェクションの可能性が増します。 クエリが最初にコンパイルされている間にストアプロシージャがコンパイルされるため、構文エラーの可能性が増します。

0

私はストアドプロシージャのアプローチを採用しています。

1

私のサイドストアからの手順は良いでしょう。

  1. ストアドプロシージャは、毎回単純なクエリがコンパイルされるたびに繰り返しコンパイルされません。

  2. ストアドプロシージャはサーバー側で実行するため、ネットワークトラフィックが減少します。 SQLクエリもサーバー上で実行されますが、大きなクエリがある場合は、クライアント側からサーバー側に移動するためにストアドプロシージャとの比較に多くの時間が必要です。

0

実際に私たちのデータベース設計スキーマ(デザイン)が変更される可能性のあるコードを公開するSQLクエリを使用してください。したがって、私たちは、1つまたは複数のSQL文を含むことができる、事前にコンパイルされた実行可能オブジェクトであるストアドプロシージャを使用します。したがって、ストアドプロシージャは複雑なSQL文のレプリカです。ストアドプロシージャは、入力を受け入れて出力を返すように記述することができます。

0

クエリが控えめにしか使用されない場合は、アドホッククエリがオプションになります。ほとんどの場合、ストアドプロシージャを実行することは良いことです。

また、次の1にoptimize for ad hoc workloads optionを設定することを検討してアドホックのための最適化オプションは多くの単一使用のアドホックバッチが含まれているワークロードのためのプランキャッシュの効率を向上させるために使用されるワークロード

msdnからです。このオプションを1に設定すると、完全なコンパイル済みプランではなく、最初にバッチがコンパイルされるときにデータベースエンジンによって小さな コンパイル済みプランスタブがプランキャッシュに格納されます。これは、計画キャッシュが再利用されないコンパイル済みプランでいっぱいになることを許さないことによって、メモリの負荷を軽減するのに役立ちます。

参照:

  1. optimize for ad hoc workloads Server Configuration Option
  2. Why would I NOT use the SQL Server option “optimize for ad hoc workloads”?
関連する問題