モジュール式でありながらSQLへの複数の呼び出しを回避する

Question

SQLサーバーへのtcp接続を最終的に作成するDataAccessLayer.dllを呼び出すBusinessLayer.dllがあります。各ビジネスレイヤーのメソッドには、データアクセスレイヤーに対応するメソッドがあり、データベースのそれぞれのビューを呼び出します。

次に、1つのビジネスレイヤーメソッドで3つのビューから一度にデータを取得する必要がある場合、問題はどうなるでしょうか。これらのビューは、アプリケーションの他の領域でも個別に必要になりますが、1つまたは2つの領域では、3つすべてのビューから一度にデータをフェッチする必要があります。

オプション1：ビジネスレイヤーの個別のメソッドを4番目のメソッドで呼び出し、それぞれのビジネスレイヤーとデータアクセスレイヤーを介してデータベースに3つの異なるヒットを作成し、ビジネスレイヤーでデータをグループ化するか、

オプション2：これらの3つのビューを呼び出し、データをDataAccessLayerに返し、次にビジネスレイヤーに戻すストアドプロシージャを用意する必要がありますか？

enter image description here

上の画像では、オプション1は緑色のボックスで示され、4番目のビジネスレイヤーメソッドは、SQLボックスへの3つのヒットを開始してデータを取得する黒色のボックスで示されています。

オプション2はオレンジ色のボックスで示されています。オプション2を使用するアプローチの利点は、ネットワーク上で複数のIOヒットが発生しないことですが、データレイヤーのコードが緑色のボックスに記述されたコードを複製している可能性があります。

クライアントは、WebまたはWindowsベースのアプリケーションです。 Windowsベースのアプリケーションでは、ビジネスレイヤーは、Windowsクライアントが呼び出すサービスによってラップされます。ここで、モジュール性とパフォーマンスのバランスをどのように達成しますか？

Arseni Mourzenko · Answer

順番に：

アプリケーションが遅いと断言できるものはありますか？ パフォーマンスに関連する機能以外の要件があり、アプリケーションがもう満たさないのですか？それは感じが遅い（その場合、あなたの最初の懸念は機能しないことを書き留めることですあなたが何を期待しているのかを明確に伝える要件）？

アプリケーションが十分に高速であれば、時期尚早の最適化を行っています。しないでください。
アプリケーションをプロファイリングしたときの結果はどうですか？プロファイルを作成し、1つではなく3つのクエリを実行しているという事実が、パフォーマンスに非常に顕著な影響を与えるボトルネックであることを特定しましたか？

そうでない場合は、最初にこれを行います。プロファイリングを実行し、ボトルネックを特定します。おそらく、クエリの数（3対1）がパフォーマンスの点で最も懸念されることはないでしょう。

接続プール（Microsoft SQL Serverを使用している場合）は、接続を数回閉じて再度開くコストを大幅に削減できることに注意してください。接続が適切に閉じられていることを確認してください。つまり、リソースを破棄しています。すべてのSqlConnections、SqlTransactions、SqlCommandsなどの周りにusing () { }が必要です。コード分析と呼ばれる静的チェックツールは、適切に破棄されていないものを見つけるのに役立ちます。

ビューのプロファイルを作成することも忘れないでください。この場合、実行計画は特に役立ちます。 indexesに注意してください（必ずしもそれらが不足しているわけではなく、そこにあるものとその理由も）。ロードするデータと実際に必要なデータ（開発者がデータベースからロードするデータが多すぎるを確認し、アプリケーションレベルでのみフィルタリングする） ;これは残念なことです。データベース自体がフィルタリング作業を非常にうまく行うからです）。

ORMを使用している場合は、それが構築するクエリを監視します（そのためにSQL Serverプロファイラーを使用できます。ほとんどのORMは、データベースに送信するクエリをログに記録することもできます）。 ORMは、最適化されたクエリを構築するための最良の方法を見つけるために助けを必要とする場合があります。
cachingを使用していますか？

そうでない場合は、複数のクエリを処理する前に、1つのクエリを処理する前に、まずそれに焦点を当てることをお勧めします。ビューについて話しているので、データを変更するのではなく、読み取るだけであると想像します（ただし、Microsoft SQL Serverのビューを使用してデータを変更できます）。これは、このデータがサーバーにキャッシュされる可能性が非常に高いことを意味します。つまり、3つまたは1つのクエリの代わりに、0になります。

そのときだけ、つまり、アプリケーションがパフォーマンスの非機能的な要件に応答しないことがわかっている場合に限り、1つではなく3つのクエリを実行するために遅くなり、最適化で構成することによってキャッシュが気にならなくなる3つのクエリを1つに置き換える方法。

ストアドプロシージャを使用する必要があるとは限らないことに注意してください。特定のケースでは、3つのビューにアクセスするだけなので、4番目のビューを作成するが解決策になる場合があります。

すべてのケースで、I/Oレベルでパフォーマンスが1つのクエリではなく3つのクエリによって影響を受けることに気付いた（または信じている）ことに驚いています。

問題は、接続を2回閉じて再度開くことでした。前に述べたように、接続プールはそれを解決します。
一般に、SQLサーバーへのクエリの送信に費やされる時間は、スカラー値をクエリしない限り、データの読み取りに費やされる時間に比べてほぼゼロです。
一般に、SQLサーバーへのクエリの送信に費やされる時間は、SQLサーバーがデータをロードするのに費やされる時間ほど重要ではありません（ほとんどのSQLサーバーがメモリにデータをキャッシュするという優れた仕事をしているため、ほとんどのクエリは非常に高速になります））。