top / index / prev / next / target / source

2006-01-19 diary: blancoDb Enterprise Edition仕様 (ドキュメント) のアップロード

いがぴょん画像(小) 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

blancoDb Enterprise Edition仕様 (ドキュメント) のアップロード

blanco Frameworkの blancoDb Enterprise Edition 仕様 (ドキュメント) についてアップロードしました。

blanco Framework: blancoDb Enterprise Edition 仕様 (ドキュメント) のアップロード

blanco Frameworkの blancoDb Enterprise Edition仕様 (ドキュメント) についてアップロードしました。クラス図やシーケンス図なども載っています。

UMLのリファレンス

UMLを調べる際に下記のページを情報源のひとつとして活用させていただきました。

大量の処理件数が適切に扱うことができる必要性がある O/Rマッピング, R/Oマッピング

O/RマッピングやR/Oマッピングというものは、原則として大量の件数を適切に処理することが出来る必要性があります (しかし残念なことに そうではない O/Rマッピングツール実装がこの世には実在します)。マッピングツールの設計の都合がシステムの処理件数を制限するものであってはなりません。blancoDbは当然のことながらツールそのものとして処理件数の制限が発生しないようにしています。一方で 指定の処理件数までのデータが欲しい場合もあります。マッピングツールとして MAX処理件数指定のデータ取得の機能も同時に必要です。もちろん blancoDbは その機能も持っています。いずれにしてもマッピングツールが件数の制限を発生させるものであってはなりません。

しかし一方で このような大量の処理件数に対応するためには、マッピングツールとして closeメソッドを準備する必要が出てくるのです。closeメソッドを準備しておいてそれを呼び出してもらうという手順の強要が必要になります。これは多少なりともコーディング上の危険を伴います。これはリレーショナルデータベースの結果セット(ResultSet)の扱いと深い関わりがあります。結果セットという概念が前面に出てきて はじめてツールとして大量の処理件数への対応が可能になるというトレードオフ/ジレンマがあるのです。

このジレンマを解決するために、blancoDbでは そのツールそのものでは頑張らずに、外側側から解決するアプローチを考えています。処理定義書が自動生成するソースコードのなかで 自動closeを実現することを考えています。(メサキ的には 電文処理定義書を軸とした解決を考えています。なぜなら直近の仕事で必要だからです) あたかも ソースコード生成型の DI ですね。ソースコードによって結果セットをインジェクションしてしまうのです。これにより大量処理件数への対応と高速データベース入出力と、そして安全なデータベースプログラミングが全て実現できます。またこのアプローチの実現性については、既に実装と実用を伴った検証はずいぶん昔に済んでいます。


この日記について