DBのO/RマッピングはSQL全部カバーするもの?

サイボウズ・ラボ : CBL ActiveRecord

今更ながら、O/Rマッピングについて考えたりメモったり。

PHPでDBを使う際、いつもPEARのDBを利用して来た。フレームワークに触れる機会が増えて来て、O/Rマッピングってのがいいらしい事を耳にする。DBをO/Rマッピングする(?)場合、SQL全てに対応するべきなのかな。

ログ解析とかで、レポートをサマライズする場合、SQL使って集計する事がある。その場合、複雑なSQLになる訳だけど、それをO/Rマッピングしたクラスとかメソッドで対応できる物なのかな。メソッドというか処理の順番でどうにでもなるもの?それとも、O/Rマッピングには限界があって、楽が出来る反面限界を超えた処理は生のSQLでどうにかすべきなのかな。

軽く調べた限りでは、O/Rマッピングの目的は、構造を持った生データをオブジェクトにマッピングする事だと思う。マッピングだから、当然オブジェクトを定義する必要が無くなる。するとしても空の器としてテールブ名をクラス名とするクラスを定義するだけ、とか。

システムの保守面を考えると、システムとデータとの結合(依存)を疎にする事ができるから、O/Rマッピングの効果は大きい。ただ、DBの場合SQLみたいな軽い言語の存在があって、そこまでをマッピングで対応できるかというと、どうなんだろう。

SQLをメソッドとしてマッピング(エミュレーション?)する事は、可能なのかな。理論的には実装可能?冒頭で紹介したライブラリしか見てないから何とも言えないけど、JAVAとかPerlとか他の言語ではどの程度の物が用意されてるんだろう。

多分、ある程度までの操作に対しては最適解だけど、そこを超えると最適解ではなくなるものなんでしょう。オブジェクト指向と非オブジェクト指向を完全にマッピングしようとしても難しい。限界(制約)を抱えつつも、オブジェクト指向にとけ込ませられる様な仕組みを得られる方法だって事かな。

そう言えば、オブジェクト指向のDBってのもあるんだっけ。RDBMSが引き続き発展していく中で、どこまで伸びてくれるんだろう。

プロフィール

このブログ記事について

このページは、koshigoeが2005年12月 9日 23:45に書いたブログ記事です。

ひとつ前のブログ記事は「オブジェクト指向開発〜導入」です。

次のブログ記事は「タグはマッピングアイテム」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。