【感想】RubyOnRails 勉強会@関西とデータモデリング
デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。
Ruby勉強会＠関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。
僕はRubyOnRails初心者なので、聞きやすかった。
聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。
「何故、RubyにDOAの第一人者の渡辺さんがいるの？」みたいな。
【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない！？
渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。
懇親会で業務に携わっていると言うエンジニアの女性が、
「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」
と言っていたのが印象的だった。
後で聞いたら、Rails開発者は、データモデリングに詳しくないらしい。
RubyOnRailsで驚きなのが、複合キーを持つDAOは作れないという話。
渡辺さんは、在庫テーブルのように、品目CDと倉庫NOを主キーに持つテーブルが作れないのは痛い、と言っていたがまさにその通り。
そのために、変換テーブルを用意して、N対Nで関係付けるようにするとか話が出ていたが、大丈夫か？
【2】ActiveRecordから覗けるJavaとRubyの違い
かずひこさんとあゆさんの初心者レッスンで、ActiveRecordの説明と演習があり、とても分かりやすかった。
ActiveRecordとは、RubyOnRails用のORマッピングそのもの。
Javaに例えるなら、HibernateやSpringと同じ感覚で使える。
SQLをRubyで操作しているのと同じ感覚だった。
面白かったのは、irbを使ってActiveRecordを実演したデモ。
PersonオブジェクトとPeopleテーブルにデータをCRUDしただけなのだが、画面上半分はirbのコマンド操作で、画面下半分は実行ログで、SQLそのものが吐き出されていた。
つまり、PLSQLのようなバッチ処理を1行おきにデバッグしている感覚と同じで、感心してしまった。
ストアドプロシージャのデバッグは普通は使い物にならないから、スクリプト言語のRubyでSQLを代用する発想は面白い。
また一つ気になったのは、InsertとUpdateが同じ操作で使えること。
Javaの普通のDAOならば、Insert用マネージャとUpdate用マネージャはクラスが異なるため、意識して使い分けないといけないが、ActiveRecordならば、Rubyのオブジェクトをsaveする操作だけでいい。
【3】RubyOnRailsの弱点と可能性
DOAをやっている人から見れば、【1】のような弱点がある限り、RubyOnRailsは多分、実用的ではない。
モデリングとは、データ構造を明確に定義するのが基本だから、モデラーさんから見ると頼りないのかもしれない。
でも、ORマッピングをここまで簡単に自動生成できる環境はすごく魅力的。
モデリングは大事だけれども、データ構造(クラス図、ER図)を作っただけではシステムは動かない。
データ構造を操作する処理を入れるためにORマッピングが必要だけれども、今まで、ORマッピングがどのオブジェクト指向言語でもクリティカルポイントになっていた。
ORマッピングは、Javaをやっている人ならいつもこの箇所で開発の半分を浪費してしまうブラックボックスみたいな無駄な作業。
Rubyなら、スクリプト言語という利点も生かし、SQLをデバッグする感覚で作れてしまう。
「From Java to Ruby」という本が既に売られているようだが、今後、この流れが少しずつ発展していくような気がする。
【余談】
かずひこさんが、RubyOnRailsの本を紹介していました。
表紙の機関車の意味は何でしょう？
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- TwitterやFacebookは人力キュレーションツールとして使う(2022.10.02)
- 「現代病「集中できない」を知力に変える 読む力 最新スキル大全」の感想(2022.08.28)
- 人類は海辺から生まれた～水生類人猿説が面白い(2022.08.09)
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 物理学を攻略するためのマップ(2022.04.18)
コメント
Railsに複合キーがないという話ですが，私はそれほど欠点とは思いません．
もし，単純に一意制約を設定したいのであれば，主キー以外にユニークな制約（索引）を作ればいいだけだと思います．（ちなみに，idのような単なる連番のようなキーを「代理キー」といい，DAOでも普通のテクニックのはずです）
また，複合キーは，リレーションの階層が増えると無駄に列が多くなるため，索引を含め，領域を食うという弊害があります．
問題があるとすれば外部キーに複合キーが設定できないという点でしょう．データベーストリガを使えばそういう複合外部キーの参照整合性制約も実現可能ですが，あまりアジャイルという感じではないので，素直にメソッド経由でビジネスルールを記述すればよいのではないでしょうか？これは，ビューからも使えますから，ユーザーの入力チェックにも使えます．まさにＤＲＹ．
データの整合性は，リレーション上の参照整合性制約ですべて表現しようとする必要はないですし，それがDAOであるという定義はどうかと思います．そのおかげで，正規化してシンプルなはずのモデルを，無駄に複雑にするのは本末転倒です．
RailsはDAOに新しい可能性を与えてくれているとすら，考えているのですが，どうでしょうか？
投稿: ynishi | 2006/08/25 00:16
ご無沙汰です。奥村です。
某blikiのエントリ
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?EnterpriseRails
によると、複合キーについては、「嫌だ」ということだそうです。
クールなサングラスとロングコートを身にまとったオブジェクティブな人のためのツールであるところのRailsは、エンタープライジーな複合キーなどを取りいれる事はありえない模様。
といった戯言は置いておいて、
OOのためのフレームワークなので、特にDB周りについてDOAのために使えないのはむしろ当然だと思います。
DBの扱いが、方や底に押し隠してなるべく薄くしたい保管庫の１つ、一方はまさしくシステムそのものと、ほとんど正反対なんですから。
Railsを使うなら、モデルはRubyで表現する。DBはそのスナップショットを置いておくだけで、キーはただのID。意味（在庫は品目と倉庫で管理して、他の入庫日などとはかかわりなく１意になる、とか）のあるキーを使うなんてもっての他です。
DOAでいくなら、ERにすべてのモデルが表現されていて、DBの外にモデルがあるなんてもっての他。それはちゃんとデータモデルに表現されているべきものです。
と考えると、相容れなくて当然なのかなぁ、と思う今日この頃なのでした。
投稿: 奥村 | 2006/08/26 01:10