ODBの幻想

Cacheをさわる機会があったので、ODBやモデリングについて考えてみました。結論から言うと

ODBを使ったとしても、モデリングやO-ODBマッピングの手法はそれほど変わらない

というものです。
ODBを使う場合でも、データが重複しないように正規化は必要です。正規化された後のモデルと実際に使われる(現実を写像した)モデルの間には、ギャップがあるので、それを埋める必要があります。
かつては、ODBを使えば、そのギャップがかなり小さくなったのだと思いますが、O/Rマッピングの技術が発達した今となっては、RDBMSを使ったとしてもODBで出来るようなこと(継承、関連、埋め込みオブジェクト)はほぼそのまま出来ます。

RDBMSを使ったモデリングは、ODBを使ったモデリングに比べて手法が確立されているので、あえてODBを選ぶメリットは、今となってはないと思います。
Cacheそのものは、結構面白い製品で、ODBとしてではなくCacheネイティブな使い方をするほうが良いんじゃないかと感じました。
Cacheは、乱暴な書き方をすると、キーと値が文字列で構成されているMapです。キーはマルチディメンションでB-Treeで管理されています。値の文字列部分は、特定のデリミタで区切ることによって複数のカラムに分けることが出来ます。
例えば、Employeeテーブルがempno,ename,jobで構成されていて、empnoがプライマリキーでデリミタを仮に/だとすると

^Employee(7369) = "7369/SMITH/CLERK"

^Employee(7788) = "7788/SCOTT/ANALYST"

のように情報を格納します。情を取り出すときは、^Employee(7369)のように参照すると"7369/SMITH/CLERK"という文字列が取り出されるので、それを/で分割して各列の値にアクセスします。
jobでアクセスする場合はどうするのでしょうか。データを格納するときに、上記以外にjob,empnoをキーにしたインデックスも格納するようにします。

^Employee(7369) = "7369/SMITH/CLERK"

^EmployeeIndex1("CLERK", 7369) = "7369"

^Employee(7788) = "7788/SCOTT/ANALYST"

^EmployeeIndex1("ANALYST", 7788) = "7788"

jobがCLERKのデータを読み取るときには、EmployeeIndex1の最初のキーに"CLERK"を設定して2番目キーを読み込めば、jobが"CLERK"のempnoを取り出すことが出来るので、そのempnoを使ってEmployeeにアクセスするのです。
インデックスを知らないとデータにアクセスできませんが、APIそのものは、非常に単純なので、SQLよりは、効率がいい気がします。
必ず、インデックスを使うようになるので、出来上がったアプリは、パフォーマンスは良いでしょうね。もちろん、インデックスを使わずに全件検索も出来ますが。