top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
最近 R/Oマッピングの特徴を改めて考えさせられる機会を得ました。
最近 R/Oマッピングの特徴を改めて考えさせられる複数の機会を得ました。改めて blancoDbの仕様を思い起こし、そして R/Oマッピングツールの下記のような特徴を再確認しました。
(パフォーマンス) JDBCプログラミングのエキスパートが書いた手書きJDBCプログラムと同等のパフォーマンスおよびメモリ効率を実現することができる。 blancoDbは ECサイト向きのアーキテクチャを採用しています。
(データ量) 大量データを処理することが可能 例えば、データベースの検索結果で 1行が1KB程度のデータを100万件から1000万件について 特に矛盾もなくデータ処理することができます。不思議なことに、多くの O/Rマッピングツールでは 実メモリ容量以上の結果セットは扱うことができないのです。
(カーソル) リレーショナルデータベースのカーソルの概念を利用することができる。 カーソルを利用して行の排他や更新を行うことができます。またスクロール方向の指定なども可能です。
(プログラミングスタイル) オンラインとバッチなどの複数の種類のプログラミングを同様なコーディングスタイルで実現することができる。
…と、メリットを列挙しましたが、その反面 例えば blancoDbでは生成する R/Oマッピングにおいて手順に従った closeメソッドの呼び出しが必要となります。これはデータベースの結果セットをデータベース上に抱えおくために必要な手続きでもあります。R/Oマッピングは RDBの機能を適切に引き出す反面、closeメソッドの呼び出しなどの条件が付与されるのです。それらはトレードオフなのでしょうけれども…。※ちなみに これの解決策が皆無であるわけでもありません。例えば blancoSOAPとblancoDbとを組み合わせて利用することによって、closeメソッドの呼び出し自身も自動生成ソースコード内に隠蔽化することができる経験を持っています。
いずれにしても ナニガシかの観点をもって 自動化なり隠蔽化に取り組んでいて、たまたま R/Oマッピングでは 上に挙げたような特徴を優先してアーキテクチャを決定づけているのだ、なあんていうことに思いをめぐらせました。
今日、フレームワーク系情報交換会ということで、品川の某所を訪問し blanco Frameworkの説明をしてきました。
話の流れから、その某所にて現在開発を進めようとしているリッチクライアント・プロトタイプを見ました。あのプロトタイプは凄かったです。感動しました。プロジェクトの成功を祈ります。