R/Oマッピング
いがぴょんの日記のいがぴょん氏が「R/Oマッピング」なる概念を述べられています。
「O/Rマッピング」ではなく「R/Oマッピング」です。前者はここ数年来Java界隈で流行のキーワード*1、後者が今回いがぴょん氏が述べられている概念です。ぼくはそれぞれ「O→R」「R→O」と読み替えるとイメージがつかみやすいと思っています。
- O→Rマッピング
- Object主体のアプローチ（ObjectからRelationへのマッピングで楽ができる）。「オブジェクトの永続化」を手軽に実現しましょう、という発想が出発点。まずオブジェクト指向設計があって、永続化のためにRDBを利用するという姿勢。ほんとはオブジェクト指向DBがあれば万事うまくいくんだけど、今のところ性能面でRDBに敵わないので、しばらくはO/Rマッピングフレームワークで凌ごう、という考え方でもあるかも？RDB固有の機能にはあまり関心がない。
- R→Oマッピング
- Relation主体のアプローチ（RelationからObjectへのマッピングで楽ができる）。RDBのデータをいかに手早くオブジェクト指向の世界に持ってくるか、という考え方が根本にある。RDBにはRDBの利点があるわけだし、長年培われてきた資産やノウハウもある。RDB固有の便利な機能もある。それらをもっと積極的に活用しよう、という姿勢。
R/Oマッピングでは「あたりまえのSQLが使える」「RDBのトランザクションがちゃんと使える」という点がキーポイントでしょう。そう、いわゆるO/Rマッピングフレームワークでは、これらがうまく利用できない場合があるんです。例えばHibernateを実際の業務システムに適用しようとした時に、そのあたりで壁にぶつかることがあります。その壁を乗り越えるために抜け道（O/Rマッピングからの抜け道）を作ったりしているうちに設計の一貫性が失われてしまい、フレームワークを利用する意味が乏しくなってしまうんです。
現実のシステム開発の多くでは、この「R→Oマッピング」というアプローチのニーズは高いのではないでしょうか。既存システムのRDB構造に設計が縛られてしまうようなケースでは非常に価値があると思います。注目です。
まずは、blancoDbに触れておこうと思います。
