WebサーバーとSQLServer2008データベースが同じサーバーファーム内の異なるボックスに配置されているWebアプリケーションがあります。
モノリシックストアドプロシージャをいくつかの小さなストアドプロシージャに分割して、クライアントコードが1つではなく複数のストアドプロシージャの呼び出しを担当するようにすると、Webアプリケーションのパフォーマンスが大幅に低下することに気付くでしょうか。
追加の背景情報：
決定ロジック、更新ステートメント、そして最後にデータのセットをクライアントに返すselectステートメントを含む数百行のコードを含むストアドプロシージャがあります。
コンポーネントDLLを呼び出すクライアントコード（この意味では、クライアントコードはデータベースサーバーを呼び出しているASP Webサーバー）に機能の一部を挿入する必要があります。ただし、ストアドプロシージャはレコードセットを更新し、同じ呼び出しで更新されたデータを返します。理想的には、決定ロジックと更新ステートメントが呼び出された後、データがクライアントに返される前に、コードを呼び出す必要があります。
この機能を機能させるには、既存のストアドプロシージャを少なくとも2つの部分に分割する必要があります。1つはデータベースを更新するストアドプロシージャで、もう1つはデータベースからデータを取得します。次に、これらのストアドプロシージャ呼び出しの間に新しいコードを挿入します。
この問題を見ると、コードメンテナンスの観点から、すべての更新と選択ステートメントをシンストアドプロシージャに分離し、ビジネスロジックをクライアントに任せる方がはるかに良いと思わざるを得ません。コード。そうすれば、クライアントコードに機能や決定ロジックを挿入する必要があるときはいつでも、巨大なストアドプロシージャを変更するのではなく、クライアントコードを変更するだけで済みます。
コードの保守の観点からは、シンストアドプロシージャを使用する方が良いかもしれませんが、データベースへのトリップ数を増やすと、パフォーマンスがどの程度低下しますか？データへの最終的な結果は同じですが、私はデータベースに頻繁にアクセスしています。アプリケーションをスケールアップして需要を処理する場合、このアプローチはパフォーマンスにどのように影響しますか？
私は、特にコードのメンテナンスに影響を与える場合に、パフォーマンスの最適化を何よりも優先するわけではありませんが、Webアプリケーションを拡張する必要があるときに、足を踏み入れて頭痛の種を作りたくありません。