【PHP】フレームワーク CakePHP 3ホール目【本命】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/03/14(金) 15:16:00ID:HF9x5ODX10分で作るCakePHPアプリ for Windows
http://p4life.jp/cake/
マニュアル日本語化
http://www.cakephp.jp/doc/
日本語フォーラム
http://cakephp.jp/modules/newbb/
あとこのへんとか（初心者向けTIPS）
http://www.avatarfinancial.com/pages/cake/
CakePHP入門リンク集
ttp://pub.studio15.jp/2007/11/13/cakephp-links/
【PHP】フレームワーク CakePHP 2ホール目
http://pc11.2ch.net/test/read.cgi/php/1194976228/
【PHP】フレームワーク CakePHP
http://pc11.2ch.net/test/read.cgi/php/1163850802/
0368336
2008/03/27(木) 00:00:03ID:d9lPRB8S意外と盛り上がっててびっくり…
0370336
2008/03/27(木) 02:53:28ID:d9lPRB8Sマジかよ。それなんてイラレ？
0371nobodyさん
2008/03/27(木) 11:48:14ID:???値を省略して（空文字で）データベースに保存した場合空文字でINSERTされる。
このときのどう保存されるか動作はデータベース依存であり
MySQLは0になり、PostgreSQLはエラーになる。
https://trac.cakephp.org/ticket/4233
チケットが出ていたみたいだが、修正無しでクローズ？
これ直る見込みないんかいな。確かに空文字とNULLは違うものだが
「データベースの省略可能な数値フィールド」ってのは
数値とNULLしか入れられないんだよね。
どうせNULLが入ったフィールドをModelから読み込むと
空文字になるんだし（あってるよね？）
NULLに変換して保存したほうが実用的だと思うんだけどなぁ。
データベース間の違いも吸収したほうがいいし。
beforeSaveあたりで書き換えるか・・・
0374nobodyさん
2008/03/27(木) 17:50:07ID:???広範囲のテーブルから値を持ってくるにはどうすればいいんでしょうか
SQLならLEFTJOINを繋げて行けば済むのですが
単純にrecursiveを増やしていくとクエリの量が異常に増えて困っています
0375nobodyさん
2008/03/27(木) 19:31:16ID:???どうせ同一人物だろうからトリップつけてくれ。削除すっからさ。
0379nobodyさん
2008/03/27(木) 21:54:01ID:???アソシエーションが直接繋がっている関係なら資料は山ほどあるのですが
例えば4テーブル先まで繋がっているデータを手繰り寄せてくる場合、デバッグ情報を見ると
一旦findで取得してきた配列をforeachで回して一つ一つまたfindを使っているように見えます
結果、データ自体は取ってこれるもののSQLの発行数が異常な量になってしまいとても使う気になれません
SQLの発行を抑えつつもアソシエーションを柔軟に広げるためには、自前でqueryを使うしかないのでしょうか？
0380nobodyさん
2008/03/27(木) 22:01:13ID:???var $fixtures = array(〜〜〜);
こんな感じでfixturesをしているわけだけどさ、
なんかテーブルの生成のタイミングとか変じゃない？
テストを単体で実行すると問題なく動くんだけど、
すべて実行するとテーブルが無いとか言われることがある。
0381nobodyさん
2008/03/27(木) 23:06:17ID:???adobe社のイラレだと思うけど。
>>375
わかる。人をバカにしてばっかだよな。あおってるやつ。
見てて気分悪い。
>>376 >>377
リファレンス見てわかるならそのURL教えてあげようよ。
しかも、聞いてる 374 はある程度知識あると思うよ。
もうちょっと人を思いやる気持ちを持とうよ。
0384nobodyさん
2008/03/27(木) 23:25:34ID:???0385nobodyさん
2008/03/28(金) 00:13:02ID:???残念なやつが多い
>>379
その4テーブルはどんなリレーションなの？
で、今はどんなアソシエーションを記述してんの？
もしかしたらDB設計が悪いという可能性もある。
0386nobodyさん
2008/03/28(金) 00:51:53ID:???各フレームワークの評価目的でプロトタイプを作っていますので
特定のテーブルの再設計で問題を解決するアプローチでは応用範囲が非常に限られてしまいます
申し訳ありませんがCakePHP側での解決を求めています
例えばごく単純にモデルが
A→B→C→D
とbelongsToで数珠繋ぎにアソシエーションが設定されている場合
AのリストにB〜Dのデータを動的に付加して取得したいとすると
どのような指定をすればよいのでしょうか
SQLならJOINをただ書き連ねていけばいいのですが
0388nobodyさん
2008/03/28(金) 01:30:56ID:???0389nobodyさん
2008/03/28(金) 01:42:40ID:???初心者が他人の力借りて簡単にCakePHP評価しようなんて
CakePHPなめすぎだろ？
自分で死ぬ思いでググれボケ
0390nobodyさん
2008/03/28(金) 02:37:39ID:???できそうにない。
https://trac.cakephp.org/ticket/2931
上で同じようなこと言ってたけど対応なしにcloseされた模様。
https://trac.cakephp.org/ticket/4277
上も同様のことを言ってる。3週間ほど前。
>>377 >>383 >>387 >>388 >>389
俺もこれの具体的な解決方法を知りたいです。どうか教えてください。
0393nobodyさん
2008/03/28(金) 03:20:48ID:???今調べて出来そうにないって。こういうケースはじめてなの？
経験浅すぎじゃね。１つのサイトをCakePHPで完成させたことないやろ
0394nobodyさん
2008/03/28(金) 03:22:38ID:???いや、これに関しての日本語の情報がなかなか見つからなかったから英語の記事を探さざるを得なかっただけ。
で、CakePHPの知識がある人はこれをどうやって解決してるんでしょうか？
0396nobodyさん
2008/03/28(金) 03:56:27ID:???0397nobodyさん
2008/03/28(金) 06:59:33ID:???何でだかアンチが混じっている。
で、cakePHPは重いとか、質問者を叩いたり。
無視推奨。
つか、アンチしてる人、cakePHPを無視すればいいのにね。
0398nobodyさん
2008/03/28(金) 08:46:16ID:???日本のサイトで分からなければ、海外サイトくらい見るだろ。
分からなければWeb翻訳すればいいんだしな
0399nobodyさん
2008/03/28(金) 09:18:10ID:???トリップの付け方も知らないらしいし、ほんと終わってんな。ｗ
0400nobodyさん
2008/03/28(金) 09:20:55ID:???とてつもないバカが何人かいるな
0401nobodyさん
2008/03/28(金) 09:29:46ID:???まさしくそのtickets通りです
CakePHPは隣り合ったアソシエーション間ではJOINを繋いでSQLワンコールに最適化してくれますが
それ以上のテーブルをまたいだ関係を持とうとすると途端にクエリ量が増えてしまいます
個人的にrecursiveでアソシエーションの深度を指定する考え方は
好感が持てるのですが、負荷の高さを考えると使用をためらわざるを得ません
サブクエリをインテリジェントに挿入しろとは言いませんが
今回の様な使用頻度の高いと思われる(かつ、割と実装の想像しやすい)処理ならば
既に解決された方がいらっしゃるのかと質問に至りました
--
先ほどContainableBehaviorを試してみましたがクエリ量は変わりませんでした
やはりコアに直接手を加えないといけないようですね(´・ω・`)
0402nobodyさん
2008/03/28(金) 10:01:46ID:???モデルにB→Aのアソシエーションも記述してあると
B→Aのクエリも発行される
だから
A→B→C→D のようなのをそのままやっちゃうと
えらいことになる
だから、いらいないアソシエーションはunbindModelでぶった切る
あと、1.2だと発行クエリが1.1より最適化されている
（つまり、少なくなってるってこと）
0403nobodyさん
2008/03/28(金) 10:11:39ID:???明らかにアンチじゃない奴のほうがたち悪いぞ。質問者叩いてるのもそう。
>>402
>>401の問題解決にはならないんじゃない。B->Aのアソシエーションがなくても起こるから。
>>401
DBにview作れば早いと思うよ。
0404nobodyさん
2008/03/28(金) 10:15:32ID:???レベル低いよな。
ここでアフォみたいな質問してるやつは
CakePHPでサイト構築したことあるのかと聞きたいよ
0405nobodyさん
2008/03/28(金) 10:19:27ID:???もっと常識レベルでの会話して欲しいな
駄文ばっかで何の役にも立たないよ
0407nobodyさん
2008/03/28(金) 10:30:15ID:???0408nobodyさん
2008/03/28(金) 10:36:03ID:???0409nobodyさん
2008/03/28(金) 10:57:56ID:???ウェブアプリなんて画面に表示する少ないデータを
表示するだけなんだからJOINしなくてもいいと思うんだけどね。
どうせ複雑なJOINならJOINするのにも負荷かかるわけだし。
ま、パフォーマンスと開発効率のトレードオフ。
どうしても必要なら、モデルに専用の検索メソッドでも作って
自分でクエリー書けばいいんじゃない？
0410nobodyさん
2008/03/28(金) 11:00:25ID:???0411nobodyさん
2008/03/28(金) 11:03:37ID:q/btZ3WHCakePHPが人気になって普及してきた証拠かなぁｗ
アンチじゃない人はIDだすようにするか？
そうすればID出していない人はアンチってわかるし。
出したら出したで削除できるしｗ
0412nobodyさん
2008/03/28(金) 11:10:07ID:???いい質問には、マナーをもって接するが
ろくでもないレスばっかりだからな
0414nobodyさん
2008/03/28(金) 11:14:01ID:???訂正を促すのが良い返答の仕方だよ。
0415nobodyさん
2008/03/28(金) 11:14:44ID:q/btZ3WHやってみなきゃわからないじゃんｗ
0417nobodyさん
2008/03/28(金) 11:57:59ID:anJTbKapもちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います
>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません
#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
0418nobodyさん
2008/03/28(金) 12:20:53ID:???負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ
0420nobodyさん
2008/03/28(金) 12:43:39ID:???> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。
> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。
0422nobodyさん
2008/03/28(金) 12:53:20ID:???やってくうちに想像しない難点が沢山でてくるよ
0424nobodyさん
2008/03/28(金) 13:04:47ID:???最適化したいならＣＩスレにいって、このスレからでていけや
0426nobodyさん
2008/03/28(金) 13:34:05ID:???どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。
特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。
0428nobodyさん
2008/03/28(金) 13:44:02ID:???> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
シンプルではないよ。
CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。
リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。
たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。
そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。
0429nobodyさん
2008/03/28(金) 13:50:03ID:???データベースを使う場合、貧弱だよな。
あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。
0430nobodyさん
2008/03/28(金) 13:50:47ID:???なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること
サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
0431nobodyさん
2008/03/28(金) 13:52:21ID:???マシンスペックを上げろ
0433nobodyさん
2008/03/28(金) 13:55:17ID:???0436nobodyさん
2008/03/28(金) 13:56:12ID:???パフォーマンスはたいして変わんないんだけどなｗ
0437nobodyさん
2008/03/28(金) 13:57:04ID:???ユーザーが増えると重くなるのはどれでも一緒ですが？
働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ
0439nobodyさん
2008/03/28(金) 13:57:57ID:???0440nobodyさん
2008/03/28(金) 13:58:21ID:???脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ
0442nobodyさん
2008/03/28(金) 14:00:15ID:???今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ
0443nobodyさん
2008/03/28(金) 14:03:25ID:???重くなりかたが異なってくるんですが？
1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや
0444nobodyさん
2008/03/28(金) 14:05:37ID:???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=
0445nobodyさん
2008/03/28(金) 14:07:29ID:???使えていますが？ JOINが使われないってだけでしょうが。
パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。
0447nobodyさん
2008/03/28(金) 14:09:13ID:???0451nobodyさん
2008/03/28(金) 14:14:14ID:???0454nobodyさん
2008/03/28(金) 14:20:13ID:???0455nobodyさん
2008/03/28(金) 14:21:44ID:???0459nobodyさん
2008/03/28(金) 14:25:14ID:???データベースを分割してJOINが使用できなくなった。
負荷を考えるのなら、JOINなんかするより、
マシンに投資してデータベースを分割（当然マシンも増えているはず）して
アプリケーションで行ったほうがいいということです。
0461nobodyさん
2008/03/28(金) 14:31:33ID:???0462nobodyさん
2008/03/28(金) 14:37:17ID:???データベース部分は、SQLの単語（selectやfromやwhere）を
それぞれメソッドに置き換えて実行しないといけない。
なんとビックリｗ
だから糞。
0463nobodyさん
2008/03/28(金) 14:38:23ID:???$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);
$query = $this->db->get();
0464nobodyさん
2008/03/28(金) 14:38:41ID:???ただ、「マシンに投資してデータベースを分割（当然マシンも増えているはず）して」が始めからできるわけじゃないんだよね。
だからSQL発行数も含め、パフォーマンスには常に気を遣うわけで。
mixiが今はソフトウェア側でパフォーマンスを気にしてないかっていったらそんなことはないし。
>>460
パフォーマンスの話してるよ。何言ってんの？
もう面倒だからお前いいよ。
0465nobodyさん
2008/03/28(金) 14:40:13ID:???最適化して、あとは楽で速いコーディングをすればいいじゃんか。
パフォーマンスの基礎だよ？
0466nobodyさん
2008/03/28(金) 14:41:27ID:???これいいね。わかりやすい構文だ
CakePHPの
find(null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,)
これに比べれば天と地に差
■ このスレッドは過去ログ倉庫に格納されています