単一のストアドプロシージャコールまたは複数のデータベースコール？

Question

MVCアプリケーションを開発しています。このビューでは、複数の異なるクエリを持つストアドプロシージャコールを使用してデータをフェッチしたり、モデルから直接個別にすべてを呼び出すことができます。どのアプローチが良い練習をするのか本当に混乱していますか？私はほとんどすべての場合でストアドプロシージャへの単一の呼び出しのために行くだろう

おかげ

Answer 1

（私は最後に例外の話をします）。

理由：

• いくつかの余分なロジックを導入することができるストアドプロシージャを維持して誰があなたが持っているいずれかの独自の直接呼び出しで複製、またはます（パフォーマンス上の理由またはビジネス上の理由のためにそれをすること） - でも、ストアドプロシージャを維持している者との間違ったコミュニケーションのために、まったく間違っている可能性があります。 （両方を維持していても、複製に努力する必要があります）。 ＃1理由：専用インターフェイスを使用することで正確性が保証され、重複が避けられます
• DBを操作するたびに、接続を開く（またはプールから取得する）ネットワーク上のデータのマーシャリングとアンマーシャリング、ネットワークの待ち時間などが含まれます。単一のエントリーポイント（あなたのストアドプロシージャー）を持つことで、これらをより償却することができます。
• DBエンジンが単一のトランザクションコンテキスト内のすべてを持つことによって作業負荷をさらに最適化することは可能です（しかし、実際は多くの異なる要素に依存するため、何も保証されません）。私。たぶんそれは、インデックス/レコードのいくつかがDBキャッシュにバッファされているので、2番目のクエリでより速くアクセスできるように似ている2つの連続したクエリを発行するかもしれません。

可能性のある例外：アプリケーションは、あなたが最初のマルチレコード構造のヘッダをロードし、下位レベルの詳細情報を必要とする「ズーム」プロセスのようなものを持っている場合にのみ、/、ユーザーがそれらを必要とする場合。この場合、それらをオンザフライでアクセスするほうがよいかもしれません。ディテールレコードがフロントエンドに負担をかけるほど十分に大きいことを証明できない限り（つまり、現実的な負荷でテストする）ことができない限り、私は以前のソリューションをさらに好むでしょう。 「洞察力」をバックアップするための厳しいデータがない限り、この方法がより効率的であると判断するという誘惑に抵抗してください。ほとんどの場合、これはprove to be a mistakeになります。