トップページ⇒php
1001コメント282KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/08/24(日) 21:43:37ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1202521438/
0554nobodyさん2008/11/13(木) 23:25:55ID:???
やっぱり落ち担当w
0555nobodyさん2008/11/13(木) 23:27:41ID:???
もうちょっとふくらませてからｗ
0556nobodyさん2008/11/13(木) 23:41:23ID:???
いやらしい
0557nobodyさん2008/11/14(金) 13:45:00ID:???
大規模向けのFWはどれ?
0558nobodyさん2008/11/14(金) 13:52:53ID:???
ちいたん
0559nobodyさん2008/11/14(金) 13:53:13ID:???
出ると思ったｗ
0560nobodyさん2008/11/14(金) 14:12:00ID:???
ちいたん以外で
0561nobodyさん2008/11/14(金) 14:31:47ID:???
Symfony
Cake
0562nobodyさん2008/11/14(金) 14:34:00ID:???
あれ?遅いとか叩いてなかったっけか?
なぜ大規模向けと?
0563nobodyさん2008/11/14(金) 14:42:11ID:???
軽量なフレームワーク≒自由度が高い≒多人数開発では混乱を招きやすい
(重量級フレームワーク=動作が遅い)≒自由度が低い=開発のルール化度が高い≒多人数でも均一なコードレベルを保ちやすい

とはいえ、フレームワークが案件に合う合わないもあるので、
どのフレームワークを使っても、大規模開発ならプロジェクトのルールが必要だと思われ。
逆を言えば、ルールさえ作れば軽量なフレームワークでもいいと思う。
重量級フレームワークが用意してくれる機能を、自分達で実装しないとならないけどね。

あと、大規模=多人数と勝手に解釈したけど。
0564nobodyさん2008/11/14(金) 14:50:52ID:???
数年がかりの本当に大規模なものなら
逆に自由度が高いフレームワークを使って自分たちで実装したいって需要もかなりある
0565nobodyさん2008/11/14(金) 15:31:36ID:???
>>564
開発期間が数年？PHPでそんな案件はほとんど無いけど。

あと、それを適当にやると、どんどん「フレームワーク」自体に修正が入ってしまって、地層のように
古いコーディングとより新しいコーディングがどんどん積み重なって手に終えなくなる。
やるなら、全くいじらないか、最初にきちんと徹底的にいじって固めてしまうのがいいのかな？
0566nobodyさん2008/11/14(金) 16:00:34ID:???
１年未満じゃ大規模とは言えないし
0567nobodyさん2008/11/14(金) 16:19:50ID:???
webアプリで開発に何年もかかってちゃビジネスになんね。
0568nobodyさん2008/11/14(金) 16:22:17ID:???
PHPはインタフェース部分を担当するに過ぎないから
プロジェクト全体で数年っていうのはあるよ
複数サイトを作るような事業でも共通フレームワークを作成することはあるし
0569nobodyさん2008/11/14(金) 16:31:35ID:???
単純にスピードを比較したものがよく出るけど、あまり意味無いよな。
しかも素の状態に近いベンチとか。

もちろん非常にシンプルに作りたいときにFWの軽さは重要かもしれないけど。
色々な機能を実装するなら、結局ある程度の重さにはなるだろうし。
だったら多少重いといわれる高機能FWを使用したほうが開発効率は良いと思う。

単純なスピード比較がよく話題が出るから、疑問に感じていた。
0570nobodyさん2008/11/14(金) 16:52:52ID:???
何が言いたいのかさっぱりだ
帰れ
0571nobodyさん2008/11/14(金) 22:44:45ID:???
必要な機能に一番近いものを使えばいいねん
多すぎず少なすぎず
0572nobodyさん2008/11/14(金) 23:35:14ID:???
それがベストだけどちょうどいいFWってそうはない気も。
まぁ、一番近いものを選べばいいが
0573nobodyさん2008/11/14(金) 23:36:59ID:???
フレームワークなんて多機能な奴はほとんど一緒だけどね
パフォーマンスくらいしか差が無い気が
0574nobodyさん2008/11/14(金) 23:49:38ID:???
大規模の意味は100万ユーザ以上が使うというアクセス数の意味で
開発の工数ではなかったけどためになった

アクセス数という意味では軽量かどうかが非常に重要と思われ
サーバの台数などのメンテナンス代が高くつくから

とはいえ重量級のものを使ってあとからプロファイリングして
リファクタリングなりすればいいような気もしてきた
0575nobodyさん2008/11/14(金) 23:58:04ID:???
必要な機能なら実装しなきゃならないんだから
効率的な実装になってるならいいんだけどね
cakeは実装が酷いよ
0576nobodyさん2008/11/14(金) 23:59:29ID:???
cakeはインターフェイスが全てだからじゃん
その辺までRailsを踏襲していると言えばそうかも
0577nobodyさん2008/11/15(土) 02:26:07ID:???
ウェブアプリで、大規模って言うと、アクセス数が多いって意味で使われることが多いんじゃないかな。
でも、それってフレームワークはあんまり関係ないよな。ハードウェアスペックとか、もっと低いレイヤーの問題であって。
PHPに限らずウェブサイトの開発で数年かけるなんて、まず有り得ないと思う。官公庁のサイトで、手続きが面倒とかでない限り。
GmailとかGoogle Mapsでもそこまで行かないでしょう。まして、よくあるショッピングサイトやSNSみたいなのに1年も時間使ってたらアフォだよ。
0578nobodyさん2008/11/15(土) 02:37:10ID:???
アクセス数の多さはフレームワークのスレで大規模にあたらないだろ
１ページだけのHTMLを出力するサイトでも大量アクセスがあれば大規模なのか？
俺は普通コード量とか機能数だと思うけど
0579nobodyさん2008/11/15(土) 02:38:10ID:???
Googleは独自のフレームワーク作ってそうだけどね
てか絶対作ってる
他にも大企業は手の込んだ事やってそうだけどなあ
0580nobodyさん2008/11/15(土) 02:50:13ID:???
ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
これをひたすら繰り返して巨大化するだけ。
0581nobodyさん2008/11/15(土) 02:53:39ID:???
機能によっては違うこともあるんじゃないか。
ユーザからのデータを何かしら加工するとか、
なにか特別なアルゴリズムでデータを収集して、
それを提供するとか。
0582nobodyさん2008/11/15(土) 03:02:01ID:???
ＷＥＢＡＰＩの提供に際する共通機能とか
自動的にＤＢを保守してくれたりＨＤＤ壊れたらバックアップの方へ自動的に繋いで新たなバックアップ先を作るとか
（ＰＨＰコード内の接続先ＤＢサーバＩＰが動的に変わるって事ね）

思いつきで書いた
0583nobodyさん2008/11/15(土) 04:39:48ID:???
ウェブアプリで大規模とそれ以外の境目はウェブアプリ側がスケーラビリティを気にする必要があるかどうかだと思う。
0584nobodyさん2008/11/15(土) 05:03:15ID:???
>>580
> ウェブアプリで機能の数って言っても、単に画面を増やしていくだけだからなあ。
> mixiとかamazonとか、確かに画面数は多いけど、結局のところ、掲示板作るのと変わりはない。
> ユーザからの入力を受け取って、何枚かのテーブルを更新して、テーブルをSELECTしなおして、文字列を加工してHTMLに埋め込むって言う。
> これをひたすら繰り返して巨大化するだけ。

それはウェブアプリだからではなく、SNSやオンラインショップという
システムが、そうなっているってだけだろ。

たとえば、YouTubeのようなウェブアプリではエンコード技術が使われる。


0585nobodyさん2008/11/15(土) 05:05:22ID:???
それにウェブじゃないシステムが何をしているかというと、
結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
0586nobodyさん2008/11/15(土) 05:47:54ID:???
大したことやってないのにフレームワークは重いから使わない(ｷﾘｯ
なんて言っちゃってる企業とか腐るほどあるからなぁ
0587nobodyさん2008/11/15(土) 09:41:57ID:???
>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？
0588nobodyさん2008/11/15(土) 13:00:48ID:???
フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし
0589nobodyさん2008/11/15(土) 13:15:36ID:???
何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。

論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。
0590nobodyさん2008/11/15(土) 14:11:03ID:???
12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。
0591nobodyさん2008/11/15(土) 14:39:00ID:???
大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?
0592nobodyさん2008/11/15(土) 14:39:25ID:???
論理削除自体間抜け
0593nobodyさん2008/11/15(土) 14:54:51ID:???
論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。
0594nobodyさん2008/11/15(土) 14:55:03ID:???
論理削除は必要だろ。
0595nobodyさん2008/11/15(土) 15:09:50ID:???
スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？
0596nobodyさん2008/11/15(土) 15:11:46ID:???
>>593
わかんね。
フラグじゃなくてカウンタにするってこと？
0597nobodyさん2008/11/15(土) 16:06:02ID:???
大規模向けではなく一番スケールアウトしやすいFWは?
0598nobodyさん2008/11/15(土) 16:34:55ID:???
スケールアウト考えたらモデルは自分で書かないときつくね？
0599nobodyさん2008/11/15(土) 16:57:52ID:???
ちｒｙ
0600nobodyさん2008/11/15(土) 17:24:52ID:???
>>595
deleted（datetime）がnullかどうか
0601nobodyさん2008/11/15(土) 17:52:20ID:???
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
0602nobodyさん2008/11/15(土) 17:55:22ID:???
勝手に値はいるのはtimestampだけだっけ？
0603nobodyさん2008/11/15(土) 18:02:15ID:???
>>602
NOT NULL にしておいて default を設定すれば入るだろ
0604nobodyさん2008/11/15(土) 18:49:10ID:???
mysqlはデフォルト値に関数が使えない
0605nobodyさん2008/11/15(土) 18:51:03ID:???
>>600
deletedってどういうこと？
0606nobodyさん2008/11/15(土) 19:09:25ID:???
フィールド名じゃないの？
0607nobodyさん2008/11/15(土) 19:12:51ID:???
ああそういうことか、関数かと思ったｗ
0608nobodyさん2008/11/15(土) 19:13:24ID:???
nullだとインデックスが使われないから論理値のほうが良くない？
0609nobodyさん2008/11/15(土) 19:27:12ID:???
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
0610nobodyさん2008/11/15(土) 19:54:48ID:???
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
0611nobodyさん2008/11/15(土) 22:00:11ID:???
>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない
0612nobodyさん2008/11/15(土) 23:07:45ID:???
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。

あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
06135952008/11/15(土) 23:12:27ID:???
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
0614nobodyさん2008/11/15(土) 23:21:42ID:???
論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！

と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
0615nobodyさん2008/11/15(土) 23:47:46ID:???
>>612
頭文字使うぐらいなら、enum型かSET型じゃね？
まぁ、DB実装によって違うかもしれんけど。
0616nobodyさん2008/11/16(日) 02:05:02ID:???
論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ

>>615
そうだね。
0617nobodyさん2008/11/16(日) 02:08:47ID:???
論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
0618nobodyさん2008/11/16(日) 02:19:28ID:???
そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm
0619nobodyさん2008/11/16(日) 03:13:45ID:???
処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
0620nobodyさん2008/11/16(日) 06:39:55ID:???
だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう
0621nobodyさん2008/11/16(日) 06:56:48ID:???
論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。

言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
0622nobodyさん2008/11/16(日) 09:11:01ID:???
>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。

削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
0623nobodyさん2008/11/16(日) 12:27:21ID:???
partial index 使っちゃう。
0624nobodyさん2008/11/16(日) 12:33:30ID:???
>>622
詳しく
0625nobodyさん2008/11/16(日) 13:00:36ID:???
>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。

書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ

＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
0626nobodyさん2008/11/16(日) 13:06:04ID:???
こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
0627nobodyさん2008/11/16(日) 13:24:25ID:???
って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。
0628nobodyさん2008/11/16(日) 13:45:33ID:???
>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
0629nobodyさん2008/11/16(日) 13:51:02ID:???
酔っ払いめ！ｗｗ

さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
0630nobodyさん2008/11/16(日) 14:12:40ID:???
>>629
そういうのの設計はちょっと知りたいなーと思っていたんだけど、
MediaWikiのソースでも読めばいいのかな？
0631nobodyさん2008/11/16(日) 14:19:46ID:???
PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも
0632nobodyさん2008/11/16(日) 14:26:24ID:???
設計見るのになぜソースを読む
0633nobodyさん2008/11/16(日) 14:43:16ID:???
オープンソースソフトウェアの設計書なんて公開されてる？
0634nobodyさん2008/11/16(日) 15:05:16ID:???
おそれすになったな・・・

>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。

画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
0635nobodyさん2008/11/16(日) 15:05:49ID:???
>>633
設計書 = ソースコード
0636nobodyさん2008/11/16(日) 15:33:36ID:???
>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。

>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
0637nobodyさん2008/11/16(日) 17:24:18ID:+7h73lOI
タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
0638nobodyさん2008/11/16(日) 17:26:45ID:???
>スペース区切りでtextカラムに入れて、全文検索
これはひどい
0639nobodyさん2008/11/16(日) 17:28:47ID:+7h73lOI
そうですか？ググっていたら同じようなことしてる人もいますが。
http://blog.nomadscafe.jp/archives/000643.html
他にいい方法があれば教えてください。
0640nobodyさん2008/11/16(日) 17:43:46ID:???
タグ単位で編集とかしないならいいんじゃない？
0641nobodyさん2008/11/16(日) 17:44:48ID:???
普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
0642nobodyさん2008/11/16(日) 17:45:10ID:???
>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
0643nobodyさん2008/11/16(日) 17:52:11ID:???
だね
基礎知識が足りてなさそう
0644nobodyさん2008/11/16(日) 17:59:55ID:???
なるほど、おっしゃる通りですね。
ありがとうございました。
0645nobodyさん2008/11/16(日) 18:01:45ID:???
俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
0646nobodyさん2008/11/16(日) 18:10:11ID:???
だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから
0647nobodyさん2008/11/16(日) 18:20:02ID:???
うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。
0648nobodyさん2008/11/16(日) 18:26:03ID:???
フレームワークの話題が無いのか
0649nobodyさん2008/11/16(日) 19:46:05ID:???
symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた
0650nobodyさん2008/11/16(日) 20:18:46ID:???
PHPの場合、標準的なDBドライバがないからな。どれも中途半端。
0651nobodyさん2008/11/16(日) 20:20:48ID:???
具体的にちんぽにーとrorでどうちがうの？
0652nobodyさん2008/11/16(日) 20:23:39ID:???
横レスだけど。
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
0653nobodyさん2008/11/16(日) 20:25:04ID:???
んなの当たり前じゃん
フレームワークの比較より言語の比較だし
0654nobodyさん2008/11/16(日) 21:54:05ID:???
フレームワークを初めてつかったけど「便利な関数群」ってだけじゃん。
■ このスレッドは過去ログ倉庫に格納されています