人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

WEBアプリケーションでSQLの発行数について、
みなさん大体1ページ表示させるのにこのぐらいに抑えたいとかありますか?

一度にデータを取るか(SQLの発行数は小、データ量は大)、分けてとるか(SQLの発行数は大、データ量は小)でどちらにしようか悩んでます。

今は分けて取得しており、スピードは問題ありませんがSQLの発行数がちょっと多くて気になってます。

どちらにしたほうがいいですか?
(データ数とかによっても変わると思いますが、その辺も含めてお答えいただければ・・・)

●質問者: pirokyun
●カテゴリ:コンピュータ ウェブ制作
✍キーワード:SQL Web アプリケーション スピード データ
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● tomo_k
●70ポイント

経験上は可能な限り一つのSQLにまとめてしまった方が速いですね。

アプリケーション側がマルチスレッドでもない限りアプリケーションサーバがSQLを発行→DBサーバが応答→それを受けてアプリケーションサーバが次のSQLを発行というのを繰り返すわけですから、そのたびにアプリケーションサーバとDBサーバとの間で通信が発生します。

1つのSQLにまとめられれば通信は1度ですむはずで、少々SQLが複雑になろうともDBサーバのSQL解析処理および実行と通信とでは通信の方が遅いと思われます。

自分の場合ならサブクエリーが2重3重になろうとも1つのSQLにまとめ上げる努力をします。(もっともその場合はたいてい要件がよくないのだが……)

その上で、リーダーなりDBに詳しいメンバーに判断を仰ぎSQLが複雑すぎて後々のメンテに支障を来すから分解した方がいいのか1つのSQLの方がパフォーマンスがよいのでそのままにするのかを検討します。

コメント欄3の方法でやる場合は少なくともプリペアドステートメントを使った方法にすべきですね。同じSQLを発行する場合はその方が速いので。

ただ、データの数が多くなってくるにつれSQLの発行回数が多くなるというパターンは絶対に避けた方がいいでしょう。

実運用で問題になる可能性が高いので。

◎質問者からの返答

SQLで少しずつとってくるより、一気にとって来てプログラム側で処理したほうがやっぱりいいてことですね?。

作り直してみます!!

ありがとうございます!!


2 ● redwing1
●0ポイント

いみわからん

◎質問者からの返答

ん?、1.2.のように一気にとってくるとプログラム側でちょっと処理をいれなくちゃいけなくて、

3.のようにちょっとずつとってくればその中の処理が一部楽になるのです。

なので3.で組んだんだけど、表示速度は特に遅くはないけど、やっぱSQLを何回も発行するのはよくないよね?。

何回くらいなら許容範囲なんだろ?っと思った次第です。



>普通は取得するデータ量は要件で決まっているものだと思うが?

っとb-windさんはコメントしてくれているんですけど、そもそも要件の時点でSQLたくさん発行しなくちゃいけないのなら、それは設計をやり直したほうがいいのではないかとか。

っでその分かれ目はどのくらいなのかなっっと・・・。

こんなこと思うこと自体おかしいんですかねorz

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ