08/07/18 02:33:21
その程度で痛いとか言ってたらdankogaiなんてどうなるの？
912:nobodyさん
08/07/18 20:21:15
PHPのフレームワークはpradoが圧倒的に人気みたいですね
URLﾘﾝｸ(q.hatena.ne.jp)
913:nobodyさん
08/07/18 20:43:14
Pradoってなんだよｗｗｗｗ
914:nobodyさん
08/07/18 20:47:51
これはひどいｗｗｗｗ
915:nobodyさん
08/07/18 21:11:58
pradoはかなり特殊だから信者がこぞって入れたんだろうな
916:nobodyさん
08/07/18 22:09:19
潔くPHP5だというだけで特殊扱いか。SAXが流行ってた頃を思い出すし、Pradoを俺は嫌いじゃないよ。
917:nobodyさん
08/07/18 22:37:15
いや、PHP5とか好きとか嫌い以前にね。
そのアンケート結果不自然すぎでしょｗ
フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。
918:nobodyさん
08/07/18 22:37:45
いやPRADOの特殊性はPHP5縛りとかそんなチャチなものじゃなくて
もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。
919:nobodyさん
08/07/18 23:40:48 w/EYto11
汎用性ではETHNAでしょ
920:nobodyさん
08/07/22 03:55:09
>Mapleは存在をしりませんでした。T-T。これ日本でつくられているのかな。
ワロタｗ
921:nobodyさん
08/07/23 17:01:32
URLﾘﾝｸ(radar.oreilly.com)
GAEにPerlが載ってPHP静かに脂肪ｗｗｗ
922:nobodyさん
08/07/27 19:58:30
脂肪ネタ、実は好きですｗ
923:nobodyさん
08/07/30 15:19:27
Rails の migration のように、データベースのテーブル定義を複数人で同期させる仕組みって PHP にありますか。
なんかよさそうなライブラリやツールがあれば教えてください。
924:nobodyさん
08/07/30 19:35:58
>>923
俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。
この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ
925:nobodyさん
08/07/31 12:29:49
>>924
それだとデータは再入力しないといけないよな。それは困る。
データはどうしてるの?
926:nobodyさん
08/07/31 12:52:20
924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。
つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
927:924
08/07/31 13:24:55
>>925
共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。
データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。
ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。
928:nobodyさん
08/07/31 14:10:50
>>926
>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。
それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926
929:nobodyさん
08/07/31 15:16:19
スキーマーの変更なんて、そんなに頻繁にするもんじゃないと思うけど。
つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
930:nobodyさん
08/07/31 18:57:07
＞それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。
＞なんかRailsに引け目でもあるわけ? >926
なんで引け目？ 別にないけど。
＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？
931:nobodyさん
08/08/01 23:30:29
>>930
>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926