DBへのアクセス回数は少ないほどよいのか？
mikann実装していてこのテーマについて考えることが多かった。DBへのアクセス回数は可能な限り少ないほうが良いと思うような思わないような。
mikannアクセス回数を減らすメリットデメリットの予想
- メリット
- 処理が早くなる
- SQLに処理を纏めるのでバックエンドのコードがスッキリする
- デメリット
- SQLが煩雑になりがち
- 特定の処理に特化したSQLばかりになり、取り回しが悪くなる
mikann
mikannポイント2 できるだけRDBMS上で処理する
（略）ファイルにデータを格納する場合，ファイルに対してはデータの出し入れだけを行い，データに対する処理はすべてアプリケーション・プログラム（JavaやVisual Basicなど）側で行う。RDBMSを利用する場合においてもこのようなアプリケーションの構造をそのまま当てはめると，実行性能が低下しやすい。RDBMSを利用する場合，基本的には，データに対する処理はできるだけRDBMS上で処理した方がよい。
mikannポイント3 接続処理は必要最小限にする
データベースに対する接続処理は重い処理であるため，無駄な接続処理を実施していると実行性能が低下する。
mikannここを読む限りでは、接続回数は少ないほうがいいし、処理もできるだけSQLで済ますのが良いって感じ。
mikannBard曰く
概ね、SQLへのアクセス回数は可能な限り少なくなるように実装するのがよいでしょう。SQLの実行には、データベースサーバーとの接続、SQL文の解析、SQL文の実行、結果セットの取得、結果セットの解析、結果セットの返却という一連のプロセスが必要になります。このプロセスには、CPU、メモリ、ストレージなどのリソースを消費するため、SQLへのアクセス回数が多いほど、パフォーマンスの低下を招く可能性があります。
ただし、SQLへのアクセス回数を最小化することにこだわるあまり、コードの複雑化や保守性の低下を招くようなことは避けるべきでしょう。また、SQLへのアクセス回数を減らすことは、必ずしもパフォーマンスの向上につながるわけではありません。アプリケーションの性質や使用状況によっては、SQLへのアクセス回数を減らすよりも、他のパフォーマンスチューニングの方が効果的になる場合もあります。
mikann- 概ね、SQLへのアクセス回数は可能な限り少なくなるように実装するのがよい
- アクセス回数を最小化することにこだわるあまり、コードの複雑化や保守性の低下を招くようなことは避けるべき
mikannここまでの結論
- SQLへのアクセス回数は可能な限り少なくなるようにする
- できるだけ（アプリではなく）RDBMS上で処理する
- コードの複雑化や保守性の低下を招くと判断される場合は、必要に応じてクエリを分割する
って感じ
mikann感想
- もっとSQLに寄せて書くようにしたい
- スパゲッティクエリを読みやすくすることと、SQLのアクセス回数を増やしたり、アプリで代替したりすることはまた別のことなんだな
- それはそれとして、実際どのくらい変わる（速くなる）ものなんだろ。そのあたりは実際のアプリで試してみたい。