ABD飲み会実施しました
羽生さんはじめ、出席してくださった皆様、ありがとうございました。おかげさまで無事に開催できました。
今回は羽生さんがABDについてまとめてくださった資料をいただいたんですが、それを見ながらお話を聞いて、これまでの理解がそれなりに正しかったことを確認できました。ただ、実戦投入はまだ早いかもしれないという由、確かに前にちょっとだけ試した感じでは、(少なくともRailsでは)まだ難しい感はありました。ERDレッスンがちょうど良いというのも実感してます。
で、Rails界隈の人がABDに興味津津なのは何か不思議、という話を高井さんがおっしゃってたんですが、それはたぶんRailsではDB設計の部分がすっぽり抜けてるんですよね。
「DBのデザインを決めたらあとはカッコよくいけるよ」というDavidさんですが、じゃあどうやってデザインすんのよ、と。いい替えると、他の部分が楽になりすぎたので、必然、残りのDB設計に関心がいく、と。このへんは興味の自然な変遷な気がしてます。
以下は昨日の話とかを受けてRails方面への適用で考えたことです。昨日の議事録ではない(たぶん昨日あの場ではほとんど喋ってないネタです)ので注意を。
Railsに乗っけるときの話
ちょっとRailsのほうに脱線しますと、RailsのORMとして有名になったActiveRecordですが、なんかRailsを使ってるときってとくに、全部ARでやりたくなっちゃって、それが意外とうまく嵌まらずにハマる、ということが多かったんですよね。いやそりゃActiveRecordパターンだけで全部解決するわけはないので当然といえば当然ですが。
するとバックエンドにDBテーブルがこないモデルクラス*1てのも当然必要になりますねと。
例えば昨日の羽生さんの資料にあるモデルが後ろにいる場合、AR的には以下のテーブルができますね、と。
- SalesActivity
- Customer
- Sale
- SalesDetail
- Product
で、最近は has_many :hoge, :through => :sales_activities でいろいろ簡単に取れて、それはそれで嬉しいんですが、実際に必要になるのは
アクティビティ(この場合はSalesActivity)が持ってるそれぞれの中身だったりします。かつ、中身も「それ .map{|o|o.nakami }でできるよ」とかでなく中身の組み合わせが欲しいんですよね。
手っ取り早いやりかたとしては
sales_activityes.each {|sales_activity|
sales_activity.customer.name
sales_activity.sales.created_on
sales_activity.sales.code
sales_activity.sales_detail.quantity
sales_activity.sales_detail.total_price
sales_activity.product.name
sales_activity.product.price
endというのがあるんですが、ちょっと見ただけでSQL投げすぎっつーかこれはひどい。eager loadingしとけばいいか、といえばそんなわけでもない。RHTMLの中から軽い気持ちでこんなのを引いた日にはもうね。というめんどくささが出てくるかと。
で、これはなにもABDに限った話ではなく、ERDレッスン的に作ってもこんな感じになったりするんでこれを何とかしたいです。一番いいのは画面(帳票も含む。様はUI)でのハンドリングが楽な構造でのデータを一発で引いてこれればよいんですが、現状はAR的な解はないなぁ、と。
で、これは ビュー(DBのほうの)でいけそう、とか、acts_as_view プラギンで論理和|論理積を指定するとJOINしてくれる、とか has_many *ファミリーでテケトーにStructに突っ込んでくれれば十分うれしいから has_many :zip と命名しようとか、そういう感じの話をしたのが2ヶ月前の勉強会でした*2。
で、まぁStructなんかを使うと、上で書いた
するとバックエンドにDBテーブルがこないモデルクラスてのも当然必要になりますねと。
につながる、と。
というか
そもそもユーザが見たいデータの構造とDBに格納したいデータの構造は違っているんだから、ARパターンのみでは行けないのは当然だし、リレーションをいじるための方法(belongs_toとかhas_manyとか)だけでやっていくのも逆に苦しくなる、というのが最近の理解。ていう趣旨のことはERDレッスンにも掻いてありましたので、もっと早くを10回くらい読み返しとけばよかったんだろうなぁ＞私。
そこを埋める、多くて3行、理想は13文字くらいのメソッドで簡単に取って来れると、RailsでもERDレッスンの教えを活かしやすくなるんじゃないでしょうか。
ベタ書きでそれを実現するクラスを作ったのが最近、一手で定義できるように抽象化してプラギンにまとめるのはいつになるんだろ、というのがDB方面での最近の私のステータスです。
