>>119
> 複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
> ほうが扱いやすいです。

XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、

・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
・referenceは結局ID属性を使いまくりになる。
・そのときの排他制御がどうなるのかいまひとつ分からない。
・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。

というあたりが不安視するところです。

> そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
> 即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
> 状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
> という仕組みに使われているはずです。

なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
＃competitorはRDBじゃなくてCORBA。

ObjectStore限定の性質なのか、OODBに共通して見られる特徴なのかは分かり
ませんが、確かにそれは便利そうです。RDBで無理にやろうとしたら定期的に
リクエストを投げてpollingしなきゃいけないところです。

やはりOODBは組み込み向け（機器組み込みじゃなくてアプリケーション組み込
み）に向いている感じがします。

だとするとベンダの営業文句は根本的にはずしてる気がする。今はどうか知り
ませんが、かつては「次世代の企業内基幹システムはオブジェクト指向開発が
広まってOODBだ!」っていう風じゃなかったでしたっけ?