>>390
まさしくそのtickets通りです
CakePHPは隣り合ったアソシエーション間ではJOINを繋いでSQLワンコールに最適化してくれますが
それ以上のテーブルをまたいだ関係を持とうとすると途端にクエリ量が増えてしまいます

個人的にrecursiveでアソシエーションの深度を指定する考え方は
好感が持てるのですが、負荷の高さを考えると使用をためらわざるを得ません

サブクエリをインテリジェントに挿入しろとは言いませんが
今回の様な使用頻度の高いと思われる(かつ、割と実装の想像しやすい)処理ならば
既に解決された方がいらっしゃるのかと質問に至りました

--
先ほどContainableBehaviorを試してみましたがクエリ量は変わりませんでした
やはりコアに直接手を加えないといけないようですね(´・ω・`)

A→Bのクエリ発行したときに
モデルにB→Aのアソシエーションも記述してあると
B→Aのクエリも発行される
だから
A→B→C→D のようなのをそのままやっちゃうと
えらいことになる

だから、いらいないアソシエーションはunbindModelでぶった切る

あと、1.2だと発行クエリが1.1より最適化されている
（つまり、少なくなってるってこと）

>>397
明らかにアンチじゃない奴のほうがたち悪いぞ。質問者叩いてるのもそう。

>>402
>>401の問題解決にはならないんじゃない。B->Aのアソシエーションがなくても起こるから。

>>401
DBにview作れば早いと思うよ。

質問があまりにもバカすぎて・・・
レベル低いよな。
ここでアフォみたいな質問してるやつは
CakePHPでサイト構築したことあるのかと聞きたいよ

あまりにもバカみたいな質問にバカみたいな回答が多すぎ
もっと常識レベルでの会話して欲しいな
駄文ばっかで何の役にも立たないよ

>>405
それそのまま>>405に当てはまるのわかる？

もっと常識的な質問たのむ

かわいそうに

バッチ処理で長くかかる処理をやるのなら話は別だけど
ウェブアプリなんて画面に表示する少ないデータを
表示するだけなんだからJOINしなくてもいいと思うんだけどね。
どうせ複雑なJOINならJOINするのにも負荷かかるわけだし。

ま、パフォーマンスと開発効率のトレードオフ。
どうしても必要なら、モデルに専用の検索メソッドでも作って
自分でクエリー書けばいいんじゃない？

もっと常識的な質問たのむ

アンチがしつこくネガティブキャンペーンするのも
CakePHPが人気になって普及してきた証拠かなぁｗ

アンチじゃない人はIDだすようにするか？
そうすればID出していない人はアンチってわかるし。
出したら出したで削除できるしｗ

アンチを勘違いしてると思うが
いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな

>>411
自治厨乙。
だいたいにして、IDなんていつでも変えれるんだから意味ないじゃん。

ろくでもないレスは無視するかマナーをもって
訂正を促すのが良い返答の仕方だよ。

>>413
やってみなきゃわからないじゃんｗ

>>415
どんだけ必死なんだよｗ

>>409
もちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います

>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません

#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが

>>417
負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ

>>417
今頃フレームワークの評価とか手を出すとか、どんだけ遅れてんだよ
この業界は進歩が早いの知ってる？

>>417
> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。

> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。

>>417
やる前にあれこれ聞かずにやってみろよ
こんなとこで解決できれば苦労しねーよクソが

評価なんてソース解析して自分で実際にサイト構築しないとわからねーよ
やってくうちに想像しない難点が沢山でてくるよ

>>417
速度重視とか柔軟性考えるならＣＩにしろや

CakePHPを最適化させにくいフレームワーク
最適化したいならＣＩスレにいって、このスレからでていけや

>>420

っていうかJOINにならないというのは
どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。

特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。

>>426
どのフレームワークも同じなら軽量でサクサク動作するＣＩの方がマシ

>>417
> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると

シンプルではないよ。

CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。

リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。

たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。

そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。

なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。

CIはデータベースを使わない。使う頻度が少ない場合にはいいけど、
データベースを使う場合、貧弱だよな。

あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。

>>428
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること

サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する

> 既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
マシンスペックを上げろ

>>429
複雑なアソシエーションはＳＱＬ直書きになるんならＣＩが理にかなってる

複雑なものじゃなくてシンプルにしようと考えような。

>>426
symfony(というかpropel)はJOINになる

>>431
ユーザーが増えるたびに、どんだけマシンが必要になるんだよ

JOIN使わないで一回一回よんでも
パフォーマンスはたいして変わんないんだけどなｗ

>>435
ユーザーが増えると重くなるのはどれでも一緒ですが？

働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ

>>436
変わるよ　あほか

ＳＱＬ直書きになる機会が多いならＣＩがいい

O/Rというのはリレーショナルデータベースからの
脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ

>>437
ずっと開発してるわけじゃねーからｗ
人件費とか１回ぽっきりやん

複雑なＳＱＬならＯ/Rマッピング使えないじゃん
今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ

>>437
重くなりかたが異なってくるんですが？

1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや

ぷｗ 頭固いな。mixiの話とかしらんのかいな

mixiでは”高負荷に耐えるためにJOINを使っていない”んだよ。

http://www.google.co.jp/search?hl=ja&rlz=1T4GGIH_jaJP221JP221&q=MIXI+MYSQL+JOIN+%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3&lr=

>>442
使えていますが？ JOINが使われないってだけでしょうが。

パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。

>>441
マシンスペックを上げるのも一回ぽっきりですが？

>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

group byとかどうやんの？

>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

この発言無理がありすぎやろｗ

>>444
あのさ、読解力なさすぎ。
「高負荷に耐えるためにJOINを使っていない」とは書いてない。