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

【PHP】フレームワー� ..

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