お気に入りの登録機能を実装するときにどうしようかなと思っております。 単純に考えると、お気に入りを登録する対象を設定しておき、その対象設定に基づき、モデルを作成します。もしテーブルがなければモデル作成の前にテーブル作成してもいいです。
例えばshopsにお気に入りを登録するという設定がされている場合、shop_likesテーブルを作成して、ShopLikeモデルを作成するわけです。でもshopsにlike_countみたいなお気に入り数を登録したい場合もあるでしょうから、shopsが対象に設定されているのに、like_countがフィールドとしてつくられていない場合は、それも事前に作成してもよいと思います。
しかしながらそうなると、モデル作成関数の実行前にこれら全てを実行する必要がありますので、テーブル作成関数というモデル作成の前段のフェーズをもう少しきちんと考えた方がいいのかなとも思う訳です。おまけにいうと、僕は今Bakeの設定のためのデータベースと、Bakeによって作成するデータベースを同じにしてしまっております。これを分けること自体はもちろん可能だと思うのですが、どうも頭の中でこの2つが混在しているようです。つまりいざ分けようとするときに、あらわけられないじゃんこれじゃあという風になるだろうと思っている訳です。
本来であればというか理想としてはBakeのための設定情報データベースのみから、Bakeにより作成するテーブルを全て新規で作成し、 それに基づきモデルを作成し、、、という流れであれば一番分かりやすいわけです。しかしながら、それはそれで大変でありますし、phpmyadiminを使えばデータベースの作成というのは割とすぐにできるものであり(簡単なものならですが)ますので、そのテーブル情報に基づきBakeするという考え方は、踏襲してもいいのではないかと思っております。
なので、最終的に納品するような状態になった場合に限り、設定情報に関連するテーブルを削除するという考え方で進めればいいのだなと今思いました。となるとまあ今のまま進めていいのか。
defaultデータベースにお気に入り設定に関するテーブルを作成しまして、そこに対象となるモデルを登録するようにします。 Bakeの前段でテーブル作成関数を実行して、そこでお気に入りに関する未作成のテーブルを作成するようにします。 となると、画像登録(Filebinder)に関する未作成テーブルもそこで作成することになります。なにしろ、機能毎に別個でテーブル、モデル、コントローラー。。。という風に作成していくと、不整合が生じてしまいますので、テーブル、モデル、コント、、という流れの中で全機能をつつがなく実装していく必要があるわけであります。