top recent

データペース

目次

  1. RDBSからオブジェクトを取り出すための設計についての考察...
  2. ObjectのRDBマッピング...
  3. RWiki:PRb...

RDBSからオブジェクトを取り出すための設計についての考察

http://www02.so-net.ne.jp/~greentea/doc-jp/rdbs-ruby/

-- ObjectのRDBマッピング (#2) もよろしく。

signature: URL

[[id:246]] 2002-02-07 13:39:02

ObjectのRDBマッピング

そんなことより RDBSからオブジェクトを取り出すための設計についての考察 (#1) よ聞いてくれよ(違 。こんなのもよろしく。
http://todo.org/cgi-bin/jp/tiki.cgi?c=v&p=Object%A4%CERDB%A5%DE%A5%C3%A5%D4%A5%F3%A5%B0

----
自作したそうですが、契約上ブツは会社のもの、って感じですか？--Ｃａｋｅ

やっぱそうなりますかねぇ(ひとごとのように…

なにぶんにも初めて(のjava)だし、ばたばた無理矢理作ったり
特殊ニーズ(一般的ではない非RDBなDBへのアクセスとか)があったりなので
機会(?)が有ったらリファクタもとい作りなおしをしたいものです。
signature: URL

[[id:248]] 2002-02-16 22:30:46

RWiki:PRb

http://www.jin.gr.jp/~nahi/RWiki/?cmd=view;name=PRb
「永続化できるオブジェクトでRubyに似ているなにか。」

「PRbはRDBMSのテーブルをオブジェクトのメモリ空間の代わりに使うOODBもどきです。現在のバージョンはDBI/DBD/Pgを経由でPostgreSQLを利用します。」

----
激しくヤラレタ!!!!!

クラス単位で情報をどう保存するかを悩むかわりに、
クラス(から生成されるインスンタス)には「色々な名前の」属性がついている
というメタな部分に注目したわけですね。
オブジェクトをそのままじゃなく輪切り(?)にした感じ。

これ(この案)は素晴しい!!!
むしろこのやり方だとインピーダンスミスマッチも比較的気にならんだろな。
やっぱりメタまんせーってことで。

インスタンスを読み書きするときは、複数のtableを結合したりすることになるんでしょね。
鯖にちょっとした負担をかけますが、今時のcpuなら以下略かも。
#RDBの正しい使いかたとは、こういうのを言います(^^;

あとtransactionを使えない MySQL とかだと
1つのinstanceの更新の間の安全性を保証するためには
なんか手段が必要かも。
リビジョン番号の管理(俺のアレには昨日実装しました(^^;)をすればいいのかなあ?

従来の(直感的な)、クラスとテーブルをおおよそ一致させるというアプローチと比べると、
従来の(直感的な(笑))データベースのadministration手順(??)は
通用しなくなるわけで、古い人(笑)には敬遠されそう、ってのは
あえていえば欠点か。尤も人のほうを教育しなおすほうが有意義だろうが。

ガベコレかあ。symbol表のほうもガベコレできるように
いずれはやらないと駄目だろうな。
ガベコレ&ID再利用は、table freelistとか作っておけばいいのかな?(^^;
ガベコレってIDを返却することに他ならないからね。
で、freelistは返却されたIDの記憶場所と見なすことができる。

knewというコンストラクタもどきメソッドの名は激ワラタ。
これってknowの過去形じゃん。
つまり「新しいフリをするが実はもう知っていたんだよーん」という痛快な駄洒落。

----
Corbis (OODB) も似た概念なのだろうか? どなたか確認きぼーん

signature: URL

[[id:278]] 2002-05-18 02:22:51

top recent

HashedWiki version 3 beta
SHIMADA Keiki