SQL発行回数を増やすかLINQで絞るか

という話を仕事でしたので、メモ。

SQL発行回数を増やす

メリット

• 特定条件で絞り込んでより少ない件数のデータが取得できる
  • SQLで少ない件数に絞り込めた場合、送られてくるデータ量は少なくて済む

デメリット

• DBアクセス回数が増える
  • クエリ発行回数が増えると、DBサーバへの負担が増加する可能性がある

LINQで絞る

メリット

• DB接続回数が少なくて済む
  • 一度に大量のデータを取得することで、データベースへのアクセス回数を減らせる
• 変更点が生じてもSQLの修正はなく、修正範囲がビジネスロジック中心で済む

デメリット

• 絞り込み精度が荒いため、一回に取得するデータ量が多い
  • 大量のデータをメモリ上で処理することになり、アプリのパフォーマンスに影響を与える可能性がある
• 複数条件でLINQで絞りこむ処理をビジネスロジックに複数組み込んだ場合、LINQの条件によってはビジネスロジックの可読性が落ちる

結論

• システムの性能上SQL発行回数がそもそもそれほどない場合は、SQLでデータ取得時点で絞り込んだほうがビジネスロジックがすっきりする
  • ただしSQL発行回数を増やせばクエリ側が増えてビジネスロジックが簡潔になる一方、SQL発行回数を減らせばクエリは減るがビジネスロジックが増える、というトレードオフの関係性のため、臨機応変に…

以下、想像など

• どちらにせよ必要なデータは取ってこなければならないので、何らかの形でどうにかするしかない
  • 考えられるのは以下か
    • ネットワーク帯域の増強
      • コストがかかる
    • アプリケーションサーバの性能増強
      • CPUの増強
      • メモリの増強
      • これもコストがかかる
    • DBサーバの分散
      • DBサーバに一度に接続されるアクセス数を制限・分散する
      • 設計と管理が大変そうだけど
  • パフォーマンスを担保するために、何を取るかという話
• X (Twitter)で、クラウドの特性の違いは各社がサーバ側に重きを置いているかネットワークに重きを置いているか、色の付け方の違いだ、というような話を見た
  • クラウドを比較検討する時の基準として、価格はもとより、このあたりの細かい仕様の違いも検討理由になりそう
    • 特性の違いは微々たるものかもしれないが、特性を理解した上でアプリをどう設計するかというのが腕の見せ所になる？
      • どこまで頑張るかの話だが…