私の同僚の 1 人は、実行パスがキャッシュされていても、ORM から生成されたパラメーター化された SQL がストアド プロシージャのように高速になる方法はないと主張しています。この頑固な開発者に何か助けはありますか?
3643 次
13 に答える
13
私はこの記事を読むことから始めます：
2つの間の速度テストは次のとおりです。
于 2008-09-08T18:26:36.777 に答える
8
ラウンド 1 - プロファイラー トレースを開始し、実行時間を比較できます。
于 2008-09-08T18:27:40.817 に答える
5
ほとんどの人にとって、説得する最善の方法は「証拠を示す」ことです。この場合、同じデータ セットを取得するためのいくつかの基本的なテスト ケースを作成し、ストアド プロシージャと NHibernate を比較して、取得にかかる時間を測定します。結果が得られたら、それを彼らに引き渡してください。ほとんどの懐疑的な人々は証拠に屈するはずです.
于 2008-09-08T18:27:08.257 に答える
5
ロブの答えにいくつか追加するだけです：
まず、テスト ケースに含まれるデータの量が本番環境の値と同じであることを確認します。つまり、クエリが通常、数十万または数行のテーブルに対して行われる場合は、そのようなテスト環境を作成します。
次に、nHibernate で生成されたクエリと s'proc 呼び出しの使用を除いて、他のすべてを同じにします。プロバイダーを交換するだけでテストを実行できることを願っています。
最後に、通常、ストアド プロシージャと ORM の関係だけでなく、さらに多くの問題があることを認識してください。そのことを念頭に置いて、テストでは、実行時間、メモリ消費、スケーラビリティ、デバッグ能力など、すべての要因を調べる必要があります。
于 2008-09-08T18:36:18.267 に答える
2
ここでの問題は、立証責任を受け入れたことです。そのように誰かの心を変えることはまずありません。好むと好まざるとにかかわらず、人々は (プログラマーでさえも) 論理に簡単に左右されるにはあまりにも感情的です。あなたは彼に立証責任を負わせる必要があります-そうでなければ彼にあなたを説得させてください-そうすれば彼は調査を行い、自分で答えを発見することを余儀なくされます.
ストアド プロシージャを使用するより適切な理由は、セキュリティです。ストアド プロシージャのみを使用し、動的 SQL を使用しない場合は、アプリケーション データベース ユーザーの SELECT、INSERT、UPDATE、DELETE、ALTER、および CREATE 権限を無効にできます。これにより、ほとんどの 2 次 SQL インジェクションから保護されますが、パラメーター化されたクエリは 1 次インジェクションに対してのみ有効です。
于 2008-09-08T18:35:05.523 に答える
1
それを測定しますが、マイクロベンチマークではない、つまりシステム内の実際の操作を表すものです。ストアド プロシージャのパフォーマンスがわずかに向上したとしても、実際のデータの取得、変換、表示など、コードで発生する他のコストに対しては取るに足らないものです。ストアド プロシージャを使用すると、ロジックが分散することは言うまでもありません。重要なバージョン管理、単体テスト、または後者のリファクタリング サポートなしで、アプリとデータベースに適用されます。
于 2008-09-08T18:27:58.443 に答える
1
自分でベンチマークしてください。サンプリングされたストアド プロシージャを数百回実行するテストベッド クラスを作成し、NHibernate コードを同じ回数実行します。各メソッドの平均実行時間と中央値実行時間を比較します。
于 2008-09-08T18:28:00.207 に答える
1
クエリが毎回同じであれば、同じくらい高速です。Sql Server 2005 は、SQL の取得元に関係なく、バッチ内の各ステートメントのレベルでクエリ プランをキャッシュします。
長期的な違いは、ストアド プロシージャは DBA にとって何倍も簡単に管理および調整できることですが、プロファイラー トレースから収集しなければならない何百もの異なるクエリは悪夢です。
于 2008-09-08T18:28:08.957 に答える
1
私は何度もこの議論をしてきました。
ほとんどの場合、私は本当に優れたデータベース管理者を獲得し、プロファイラーを実行して proc とコードの一部を実行し、結果が無視できるほど近いことをデータベース管理者に示してもらいます。
于 2008-09-08T18:28:10.237 に答える
0
抽象化レイヤーを追加すると、sprocへの純粋な呼び出しよりも遅くなります。管理対象ヒープに追加の割り当てがあり、コールスタックを追加でプッシュおよびポップするという事実だけで、問題の真実は、ORMにクエリをビルドさせるよりも、sprocを呼び出す方が効率的であるということです。 ORMはです。
それが測定可能であるとしても、どれほど遅いかは議論の余地があります。これは、ほとんどのORMにクエリの実行をまったく回避するためのキャッシュメカニズムがあるという事実によっても助けられます。
于 2008-09-08T23:48:24.257 に答える
0
ストアドプロシージャが10％高速である場合でも（おそらくそうではありません）、実際にどれだけ重要かを自問することをお勧めします。最終的に本当に重要なのは、システムのコードの記述と保守がいかに簡単かということです。Webアプリをコーディングしていて、すべてのページが0.25秒で返される場合、ストアドプロシージャを使用することで節約できる余分な時間はごくわずかです。ただし、NHibernateのようなORMを使用することには、多くの追加の利点があります。これは、ストアドプロシージャのみを使用して複製するのは非常に困難です。
于 2008-09-09T00:01:00.843 に答える
0
それを測定します。
実際、このトピックに関する議論は、測定するまでおそらく無駄です。
于 2008-09-08T18:29:11.280 に答える
0
彼が考えている特定のユースケースについては、彼が正しいかもしれません。ストアド プロシージャは、任意に調整できる SQL の複雑なセットの場合、おそらくより高速に実行されます。ただし、休止状態などから得られるものはキャッシュです。これにより、実際のアプリケーションの存続期間が大幅に短縮される場合があります。
于 2008-09-08T18:31:59.917 に答える