元スレ【PHP】フレームワーク CakePHP　3ホール目【本命】

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

401 = :

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

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

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

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

403 = :

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

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

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

404 = :

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

405 = :

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

406 = :

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

407 = :

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

408 = :

かわいそうに

409 = :

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

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

410 = :

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

411 :

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

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

412 = :

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

413 = :

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

414 = :

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

415 = 411 :

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

416 = :

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

417 :

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

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

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

418 = :

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

419 = :

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

421 = :

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

422 = :

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

423 = :

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

425 = :

>>420

426 = :

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

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

427 = :

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

428 = :

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

シンプルではないよ。

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

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

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

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

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

429 = :

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

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

430 = :

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

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

431 = :

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

433 = :

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

435 = :

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

436 = :

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

437 = :

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

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

438 = :

>>436
変わるよ　あほか

439 = :

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

441 = :

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

443 = :

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

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

445 = :

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

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

446 = :

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

449 = :

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

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

450 = :

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