元スレ【PHP】フレームワークについて語るスレ10【総合】

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

951 = :

アクセス解析を作るとしたら、
Google Analyticsでは対応できなくなったときだな。

アクセス数が少ないやつがアクセス解析を作ると
一人ひとりのアクセスしたページの履歴を見れるとか
わけのわからない機能を作りそうｗ

952 = :

アクセス解析ですが、自分のサイト内を移動するユーザーの様子は、
リファラー情報をDBに保存して集計していますか？

954 = :

IPアドレスごとの検索履歴なら
昔から永久保存してるよ

956 = :

cgi?password=

コードが全てを物語ってるじゃないか。
相手にする価値無いだろ。

957 = :

>>956
何の話?

958 = :

どこがフレームワークの話？

959 :

CakePHPのアソシエーションでInner Joinを利用してレスポンス速度を向上
http://blog.katsuma.tv/2008/12/inner_join_on_cakephp.html

インナージョインとレフトジョインて別物だし、
簡単にテレコにできるもんじゃないよね？
これってどういうことなん？

960 = :

ってかレフトジョインてそんなに遅くなるの？
今作成してるサイト、テーブルいくつもレフトジョインしてるんだが・・・

961 = :

そんなもんRDMS依存だろ。

962 = :

程度の違いはあれ、LEFT の方が遅い。
それより、CakeのモデルでINNERにできるところをLEFTにしてるとしたら
（たぶんそういうことなんだろうけど）ちょいとお粗末すぎる希ガス

963 = :

レフトジョイン→インナージョインにして問題ないのって
接続対象が0にならない場合だけでしょ
タグっぽいの駄目だし使いどころなさそう

964 = :

>>963
LEFTじゃなきゃだめなところをINNERにして動作に異常がないわけはないんで、
普通にINNERでよいところをLEFTにしてるかどうかが問題なんじゃない？

965 = :

ナルホド

966 = :

>>959
NULLが出来るクエリなんてキモチワリーってことなんじゃない？
ちゃんと設計してあればLEFT JOINなんてそんな使わないよ。

967 = :

解析プログラムはアーチンで
１日で3Gくらいのログファイルを想定してた
ディレクトリ毎にアクセス状況を表示出来るので、そちらのがディレクション側にも理解し易いかなとか
GETで渡ったパラメータも項目別に出るけど、ページ検索だか訳判らん表現に

まぁ機能以外のつまらん理由で仕様が決まる事もあるねー
以上の話題にならんかったな

968 = :

スレチかもだけど、流れ乗じて聞いてみる。
LEFT JOINの方が遅いとか、その辺の知識が弱くて困ってるんだけど、
その辺を学ぶのにいい情報源ないですか？
CRUDなSQLは一通りかけるけど、JOINなんかは解説サイトを鵜呑みにして、
とりあえず出来てるレベル。
もうちょっとしっかりとした知識を身につけたいところ。

969 = :

>>968
LEFT JOINの方が遅いという一般的な事象については、RDBMSの内部動作の基本を
理解していれば、自明。RDBMSの基礎理論を扱ったドキュメントになら書いてあるでしょう。
RDBMSのドキュメントに結合の最適化やINDEXの使われ方、処理フローに
ついて書いてあることもある。そこは運だな。

970 = :

>>969
難しいな。

971 = :

あえてお勧めの書籍やどのRDBMSのドキュメントかなどを記さないスパルタな>>969

972 = :

うーん、答えるのも難しいね
http://www.inter-office.co.jp/contents/157/
たとえば、ここにベンチ出てるんだけど、前のアイテムでLEFT JOINして性能が1/3になってるという話。
ただ、これは一般的に1/3になるというのではなく、LEFT JOINするときにどのくらいNullになるレコード
があるかによって速度は全然違うから、完全な比較はできない。
そもそも、使い路の違うものを速度比較っていう考え方自体がないんだよね。

973 = :

そりゃ1枚のテーブルに入ってる方が早いだろうけど、メンテナンス性が悪くなるじゃん。1日何百万PVもあるようなサイトなら、別の考え方もあるんだろうけどな。

974 = :

１枚のテーブル？
あんまり関係ない希ガス

975 = :

>>973
1枚のテーブルを分割したいんならＩＤ振ってINNER JOINすればいいじゃん。

976 = :

大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。

977 = :

大規模サイトでも、テーブルを非正規化するのはほどほどにしておいて、
なんでもかんでもコンテンツはキャッシュにぶちこんで、
検索が必要な場合は専用のインデックスにでも(RDBMSじゃなく、いやRDBMSでもいいけd)放りこめ!って
やりかたがイマドキはアレな気がする。

チューンしたSQLは一発書いたら使いまわしのできないコードだし、
コンテンツキャッシュがちゃんとしてれば大方はそっちの方が数字は速いし、
フレームワークなんかにも組み込みやすいし、なのでまぁそういう流れなんだと思う。
大規模サイトっつってもいろいろあるだろうけどさ。

978 = :

> やりかたがイマドキはアレな気がする。

アレってなに

981 = :

>>976
> 大規模なウェブサイトは極力ジョイン使うなってよく紹介されてるだろ。ジョインそのものの話。
知識では知っていたが、最近実感した。

JOINにかかる速度というより、
一般的にSQLを実行したとき、条件やソート処理も一緒に行う。
条件やソートにインデックスがうまく使われれば速いが、
そうでない場合大幅に速度が遅くなる。

インデックスはRDMSによるが、一つのSQLで一回しか使われなかったりと
使われない場合がある。
JOINが絡むと結果的に複雑なSQLになり、インデックスをうまく使うのが難しい。
だからJOINを使った複雑なSQLを書くのではなくインデックスを使った
単純なSQLを複数回発行するほうが良い。

982 = :

そりゃjoinしないで済むならしないけど仕方ないじゃん
1対多とか多対多を一つのテーブルでやるなんて無理ぽ

983 = :

>>977

>検索が必要な場合は専用のインデックスにでも

そうそう。Luceneみたいにインデックスに特化させたシステムを別に走らせて
DBからはデータだけを取ってくる。ページはキャッシュしとく。

984 = :

>>959
UserとProfileが一対一の関係で
しかも、
Userレコードに対応するProfileレコードが必ず存在する
という前提でないとINNER JOINは使えないと思う。

Userテーブルにたくさんデータがあって、Profileテーブルが空の場合、
$this->User->find('all');
としても、データが返ってこないことになる。

この場合CakePHPだとNULLになるのかな。

985 = :

多対多は何も考えずにJOINで表現すると激重になるらしい
といって、インデックス？のシステムを利用してどう表現するのかよくわからない
うー頭が悪い

テーブル[A]： 1:太郎 2:花子 3:ジョニー
テーブル[B]： a:バナナ b:メロン c:マンゴー
テーブル[C]： 1-a, 1-b, 2-b, 2-c, 3-a, 3-c

こうすりゃJOINなんか使わなくていいんだぜ！ってのがあるのならだれか教えて下さい。
それとも、こんなのなら迷わずINNER JOINでいいのかな・・・
件数が少なけりゃ、例えばメロンが好きな人！ってので、テーブルCから名前キーを
取得して、テーブルAから IN (1, 2) とかでセレクトできるけど・・・そういうことするんでしょうか？

てか、PHPかDBの初心者スレいった方がいいかな；_；

986 = :

DBは切り離せない存在だけど
PHPに限ったことじゃないし、DB系のスレにいったほうが
多くの情報は集まるんじゃないかなって気はするねー

っと、そろそろ次スレだね

988 = :

>>976
Google App Engineはjoin禁止

989 = :

>>985
JOINはしないほうがいいって言ったけど、
それはできるのならってことで、
JOINしたほうが自然な場合はしていいよ。

SQLパズルとでも言うべきな、
なんたらをgroup byした結果となんたらを結合して～なんて
ややこしいのはやめたほうが良いって話。

990 = :

ベンチが全てじゃね

991 = :

　　　　　　　　　　　　　 （⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒
　　　　　　　　　　　　　 （　　　　俺の生活範囲って
　　　　　　　　　　　　Ο（　　　ベンチが全てじゃね
　　　　 　　　　　ο　　　～～～～～～～～～～～～～～～～～～
　　　　　　　　　。
　　 　　　　　∧＿∧
＿＿＿／⌒（ｌ|ｌ･∀･）＿
　　 　/　| 　| 　　 ノ　| 　|
　　　|　　| 　|　／ |,　|　 .|
＿＿|　　| 　|　＼ .|　_|＿|
　　　ヽ、（＿二二⌒)__）. ＼
＿＿＿_|　　|　＼二 ⌒l.　　＼
　　　　　|　　|￣￣ |　　|￣￣||
　　　　　|　　|　　　 |　　| 　　.||
　　　　　|　　|_　　　|　　|_　　.||
　　　　 （＿＿）　　（＿＿）　 ||

992 = :

>>991
ダンボールもないのかよ(w

993 = :

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞ……！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,
　　 　 　//三/|三|＼　　　　　　　,,,,　　　　,,､,､,,,
　　　　　　∪　 ∪
　　,,　　　　　　　　　　,　　　　,,,,　　　　,,､,､,,,　　　　　　　,,､,､,,,
,,,,,　　　　∧＿∧　うまいモナー,,,,,　 　、　,,,,,,　　　,,,,,,,,　　　　,,,,,
　,,,　　　（　´∀｀）＿＿＿,,,,＿＿＿ ,, ∧＿∧ ｹﾞﾝｷﾆ ｼﾃﾙｶﾅ・・・＿＿＿,,
　 ／￣ （　つ日ヽ　 　∧＿∧　　 　（　　　　）　　　　　　　　　　　　　　 ／
／　　　 （＿＿））　　 （´∀｀　）　　　（　　　　） 　　 ∧＿∧∧＿∧ ／　マターリモナー
　∧＿∧∧＿∧ドーゾ （日ノ　）　　｜ ｜　| 　　　（　´∀｀） ´∀｀）
　（　´∀｀） ´∀｀）　　　　(（＿＿）　　,（＿（＿） （○）⊂　　 ） つ日⊂ ） モーナー
―（つ⊂　 ） つ⊂ ）―――――――――――ヽ|〃(⌒)(⌒) (⌒)(⌒)
　　　(⌒)(⌒) (⌒)(⌒)グーグー

994 = :

>>991
すごいコピペですねｗ
WebProg専用のAAでしょうか？（・∀・）

995 = :

>>994
普通にベンチでぐぐって見つけたｗ

998 = :

うめ

999 = :

うめ

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [100%] - 2008/8/24 19:04 ○
• 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
• 【PHP】フレームワークについて語るスレ13【総合】 (985) - [98%] - 2009/9/23 3:04 ○
• 【PHP】フレームワーク CakePHP　3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
• 【PHP】セッションについて語ろう！【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
• 【PHP】フレームワーク CakePHP　6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
• 【PHP】フレームワーク CakePHP　5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
• 【PHP】フレームワーク CakePHP　7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○
• 【PHP】フレームワーク CakePHP　4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○