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に触れておこうと思います。