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

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

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

http://hatena.jp

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

ＳＱＬを減らすには・・・

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

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

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

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

またＤＢというのは、ＳＱＬを実行するためのシステムであり

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

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

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

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

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

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

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

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

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

ダミーURL

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

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

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

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

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

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

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

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

• http://dev.mysql.com/doc/refman/4.1/ja/tips.html

参考になれば幸いです。

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

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

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

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

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

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

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

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

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

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

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