アクセス解析の機能を実装している際、表示データを取得するために、複数のテーブルに何度もSELECT文を叩いています。

distinctやavgが必要で、多用しているうちに何度もSQLを使っていることに気づいてガックリきています。
ただひとつの画面表示のために、例えば10回もSQL文を使うのはDBに優しくないような気がして夜も眠れません。


1ファイル内で何度もSQLを使うのはアリなのでしょうか。
強まったマシンスペックがいればアリ、というハードウェア観点は抜きにして教えてください。

また、SQL文を減らすために行っている工夫、のようなものがあればそちらもお願いします。こちらは設計見直したほうがいい、というのは抜きで。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2006/07/06 20:15:08
  • 終了:2006/07/09 22:48:13

回答(5件)

id:kokoromo No.1

kokoromo回答回数9ベストアンサー獲得回数02006/07/06 22:22:09

ポイント20pt

クエリが多くなりすぎてDBが落ちたり、パフォーマンスが落ちて画面表示の速度が遅くなっていなければ何回SQL文を発行しても問題ないと思います。

シンプルでいいのではないでしょうか。

http://hatena.jp

id:takets

ありがとうございます。

なるほど。実際のパフォーマンスで判断すればいいのですね。

実運用時にどうなるのかがわからないのでちょっと不安ではありますが…。

2006/07/07 05:50:53
id:taknt No.2

きゃづみぃ回答回数13539ベストアンサー獲得回数11982006/07/06 22:53:16

ポイント20pt

http://www.wakhok.ac.jp/DB/section2.6.5.html

SQLを減らすには・・・

Viewを使うのもひとつの手だとは思いますが、

何度もSQLを行なうのは別に問題ないと思いますよ。

だって検索かけたら必ずSQLを実行するじゃないですか。

だからといって検索しないわけにもいかないし・・・。

またDBというのは、SQLを実行するためのシステムであり

SQLを実行させないと意味がありません。

id:takets

ありがとうございます。

『SQLを何度も実行するのは悪』のようなことを言われていたため、新鮮な意見でした。

2006/07/07 05:59:59
id:m-nisi No.3

m-nisi回答回数159ベストアンサー獲得回数32006/07/06 23:08:10

ポイント20pt

私も同様の事で悩んだ経験があります。

色々考えて減らしたり出来た事もあります。

そのSQL文とかテーブルとかを見せて頂ければ

詳しい方が助言して頂けるかもしれませんね。

ちなみに、PHPからMySQLを叩く時に、

DBに優しいかどうかはともかく、

一回クエリを投げる時間が遅くて、

高速化という観点ではよろしくないかと思います。

ダミーURL

http://q.hatena.ne.jp/

id:takets

ありがとうございます。

テーブルをお見せするのは難しいのですが、パフォーマンスのためになんでもかんでも1つのテーブルに納めている形になっています。

一回クエリを投げる時間を気にしての設計かどうかは不明ですが。

2006/07/07 06:07:20
id:bonlife No.4

回答回数421ベストアンサー獲得回数752006/07/07 00:01:06

ポイント20pt

何回もSQLを発行しても特に問題はないと思いますが、あまり遅くならないように工夫はしておいた方が良いと思います。

例えば、集計した内容を表示したい場合、都度COUNTで件数を取得するよりも、件数を格納するためのサマリテーブルを用意しておき、そちらを参照させるようにすればパフォーマンスは向上するはずです。

具体的には、アクセス解析の場合、過去のアクセス数は将来変化することはないですので、集計結果用をサマリテーブルに格納しても問題ありません。

月間の実績を見せるページでは、総アクセス数/day、ユニークアクセス数/dayなどは毎回COUNTするのではなく、サマリテーブルに対してSELECTを発行すれば、テーブル全体の行数が少なくなりますので、かなりの高速化が期待できます。

(その場合でも、検索当日の分のデータだけは別途詳細テーブルから算出する必要がありますが。)

以下、MySQLのマニュアルからの抜粋です。

大きなログテーブルから統計を収集する必要がある場合は、テーブル全体をスキャンするのではなく、サマリテーブルを使用する。サマリの管理は、リアルタイムで統計を実行する場合と比較して非常に高速になる。何らかの変更がある(業務上の決定に応じて)場合は、ログから新規にサマリテーブルを再生成したほうが、実行アプリケーションの変更よりはるかに高速である。

参考になれば幸いです。

id:takets

ありがとうございます。

サマリテーブルの作成は便利そうですね。

アクセス解析は読み込みより書き込みの回数の方が多いため、あまり効果がないのではと回避していたのですが、やるだけの価値はありそうです。

リファレンスも大変参考になりました。

2006/07/07 06:14:03
id:nagi0008 No.5

nagi0008回答回数41ベストアンサー獲得回数12006/07/07 10:00:55

ポイント20pt

Oracleをご使用になる際には気を付ける必要があると思います。

SQL文を発行する度にREDOログに書き込まれ、

REDOログに書き込める上限に達した際にarchive logが生成されます。

その為、あまり何度も不要なSQL文を発行するのは

archive log出力先のフラッシュリカバリ領域が圧迫されることになり、

フラッシュリカバリ領域が溢れてしまうと、

Oracleが落ちてしまうこともあり、あまりいいことではないと思いますが、

本件についてはOracleをご使用になられているわけではなさそうなので、

性能面に関してだけ影響があるのかも知れませんね。

(全然参考にならず、見当違いのご回答で申し訳御座いません…。)

ダミー→http://www.searchdesk.com/

id:takets

ありがとうございます。

オラクルはちょっと使わないんですが、DBごとの仕様によって問題が発生することはありえることなので、忠告として受け止めておきます。

2006/07/09 22:47:50

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません