[ooaa main]  [object pasta2]   [essence] (旧blogはこちら)  [flickr]  [myspace]  [View Eiichi Hayashi's profile on LinkedIn] 

オブジェクトデータベース

どうしてもあきらめきれない数々のものの中の一つとしてあるのがオブジェクトデータベース。
優秀なORマッパーがいろいろでてきてはいるけども、所詮相手はRDBでしかない。 RDBの概念で最適化されたスキーマ構造でしかあり得ないわけで、ちょっと複雑な要件だととんでもないSQL文をつくらなければならない。EJB 3.0のEJBQLだってSQLとそう大差ない。


スキーマ設計の質の影響も大きいわけですが、業務の意味構造をRDB的にする方が現実的な解決策となってしまっている。
で結局RDBの内部実装まで考慮したSQL文を描かなければならない。正直SQL自体書きたくない。 オブジェクト指向言語のままやりたい.

その点オブジェクトデータベース”db4o”のNQ(ネイティブクエリー)はオブジェクト指向プログラミング言語でクエリーを記述できるそうで期待できる。
その実体は本当にマッチする条件のロジックをjavaの文法で記述するだけ。

チュートリアルより。

List <Pilot> result = db.query( new Predicate<Pilot>() 
  {
    public boolean match(Pilot pilot) 
    { 
      return       pilot.getPoints() > 99 
                 && pilot.getPoints() < 199 
                 || pilot.getName().equals( 
                          "Rubens Barrichello" 
                          ); 
    } 
  }); 

あたかも、メモリー内のオブジェクトを検索するかのように記述できる。
実際にメモリー内のオブジェクトを検索するわけではないので、対象のオブジェクトをすべてインスタンス化しないといけないようなロジックを書いてしまうとパフォーマンスがおちてしまう。
Java言語そのものを使っているため、そうゆうプログラムコードも書けて実行できてしまうという難点はある。

このことをコンパイラで検知するのはとてもむずかしいだろう。なぜなら意図的にインスタンスを参照するクエリーメソッドを記述しているのかどうかの判断がむずかしいから。

ともあれ、静的なクエリーを書くガイドさえあれば、かなり複雑かつ柔軟な構造を持つオブジェクトデータを簡易な記述でデータアクセスが実現できてしまう。

このまえまで、関わっていたプロジェクトもオブジェクト分析で業務の意味構造を踏襲した永続オブジェクトの構造でOODBを構成していたら開発工数はかなり削減できたかもしれない。

もっとも、OODBを使用することを説得する方に時間がかかるかもしれないが。(w

db4o自体はオープンソースで、導入実績とパフォーマンス実績があるようで、今後の発展に期待したい。

ーー
プレスリリース @Pressより

    米国db4objects社世界で始めてネイティブクエリを搭載     
 〜Bosch社が一足早く活用 さらに生産性を向上させるネイティブクエリ〜 
http://www.atpress.ne.jp/backnumber/3717.html

  • -

db4o日本語ポータル
http://www.db4o.com/japan/