Re: idea*idea CakePHP修行 #7～9「DB設計」「bake.php」「scaffold」

idea*ideaで連載中のCakePHP修行（旧：CakePHPでSNSっぽいものを作ろうとして挫折するまでのコーディング日記）が更新されましたので、例のごとくツッコミをいれていきます。

今回の内容は、DB設計、bake.php、scaffoldについてです。

UsersテーブルのemailフィールドをNOT NULLにすべきかは仕様によりけり

#007より。

ちなみにUNIQUE（引用注：emailフィールド）にはNOT NULLを入れたけどそれでいいよね？

これは、仕様によります。ユーザー登録時に「メールアドレスを後でDBに保存する」という仕様や「一時的にメールアドレスを空にする」という仕様があれば、NULL値を使うべきです。そういう仕様が無ければNOT NULLでよいでしょう。

bake.phpが微妙な３つの理由

bake.phpを使ってみる（CakePHP修行 #008）でbake.phpが使われました。bake.phpは、対話式でCakePHPのMVCの大枠を作成できるツールです。

• 「テーブルいろいろあるけど、どのテーブルのモデル作る？」
• 「バリデーションはどうする？」
• 「アソシエーション（関連づけ）はどうする？」

といった質問に１つづつ答えていくと必要なコードが書かれたファイルを書き出してくれます。（CakePHPまとめ@Wiki - bakeでその様子が伺えます）

個人的に今のbake.phpは使わないほうがよいと思っています。理由は３つ。

CakePHPで作るようなWebアプリケーションは、作りながら設計を変更することが多い

もしくは「作りながら設計する」こともあります。設計が完璧にできていないときに、いきなりモデルごとのバリデーションを聞かれても答えようがありません。コードを書く前にDB設計とアプリケーションの画面を全部起こしてから開発に取りかかるような現場では使ってもよいかもしれませんが、それでも微妙な気がします。

最初からbake.phpを使ってファイルを書き出してしまうと、変更したいときに必要な知識が足りない

個人的に一番の問題はこれだと思っています。自分でコードを書いていないので、Cake習得中の場合、変更するための必要な知識が身に付いていないため後から困ることになります。最初はサンプルコードをコピーしてファイルを作成していったほうがよいでしょう。最初は必ず命名規則を間違えてエラーを出してしまいますが、エラーによって「ここはこう書いてはいけないのだ」ということを理解できます。

では慣れたらbake.phpを使ってもよいのかというと、これまた微妙だと思います。そのわけはというと...。

そもそもファイルを作った方が早い

そもそも対話式で１つづつ作成することが、ファイルを手動で作成する速度に勝るのかという疑問があります。ひな形程度であればファイルを１つづつ作成して（２つめからはコピー＆修正で）いったほうがよいです。似たようなアソシエーションを行うモデルがあれば、コピーして流用できます。bake.phpでは他のモデルを流用することはできません。

そんなわけで、bake.phpは試す程度で

ちなみに百式の中の人にはbake.phpを試してみてもらいたかったので、あえてこのことは黙っていましたｗ 中の人も「bake.php＝面倒（かなり個人的な主観）」という結論を出しています。CakePHPについて検索していてもbake.phpが便利という言及は見たことがありません（少なくとも日本語のサイトでは）。

とりあえず今の結論としてはbake.phpはどういうものか試しておく程度でよいかと思います。

scaffoldは管理用や開発中の便利ツール

$scaffoldを試してみる（CakePHP修行 #009）でscaffold機能が試されました。

scaffoldは言うなれば「簡易DB操作GUI」です。バックグラウンドのシステム管理者用や、開発中にデータを修正するためのインターフェースを用意するときなどにとても便利です。

便利さとひきかえにカスタマイズ性を犠牲にしているので、全体公開用にscaffoldが使えるケースはほとんど無いでしょう。

今回は以上です。