OODB - オブジェクト指向データベース

**名無しさん＠お腹いっぱい。** · 03/07/02 23:49

javaの盛り上がりでOODBに移行していくと思いきや
O-Rマッピングかよ！
語りやがれ！

**NAME IS NULL** · 04/08/25 00:52

ところで >>150 のページは、内容に対して
著者イラストが若すぎる気がしないか？age

**NAME IS NULL** · 04/08/25 15:09

＃あまり過度にRDBの肩を持つのも嫌だけど。
>>151
設計というよりも実装の話ですよね?

オブジェクト指向でも親が子の情報を持つわけではなくて、子へのポインタを
持つだけなんじゃないでしょうか。設計において親子関係であることを定義す
ることって出来ましたっけ?(継承時にサブクラスであると宣言するように。)
設計者と利用者の間で合意を取っているだけだと思います。

RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
「left outer join」に相当するわけだし。

OODBだと単純に持たせただけだと、子から親へ辿るのがめんどくさくなっちゃうでしょ?
特定の明細件名をもっている伝票番号一覧を出すとか。
＃双方向リンク用のライブラリ等がどのぐらい普及しているものなのかはよく
知りません。

オブジェクト指向でも「期間を限定した伝票明細の検索」は、「検索」機能を
利用するでしょう? キーを指定してサーバへリクエストする代わりに、属性
名や配列の添え字がソースコード中にハードコーディングされているし。

＃私はRDBのjoinとOODBのpointer traverseは設計上の意味合いはほぼ同じと
＃考えているけど、ここは合意が取れるのかな。

RDBで明らかに足りない、あるいは普及していないのは、型チェック機能など
でしょうね。
IDの更新に対する保護機能も無いし。

**NAME IS NULL** · 04/08/25 15:19

>>152
> トランザクションをサポートしていないデータベースなんて使えないですよ:-)
だからインタフェースよりもそっちの方が重要だし、コンパイラに渡す文字列
を書きやすくするためにそっちへしわ寄せが行っていないか、十分検討したい
です。

> インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
> と思います。
ObjectStoreの「コレクション」は普通の意味とニュアンスが違っていたよう
な。Collection型とかとは違うんですよね?

> 排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
> 単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
> するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
> 最悪デッドロックの嵐になります。

＃クラスタ単位がどのようなものか分からないので外しているかもしれませんが。

「仮想ページがそのまま」というのから想像すると、コンパイラをhackしてヒー
プ領域の使い方を指示できる、という理解で良いでしょうか。

そこまでする必要があるなら「プログラム実行イメージをそのまま格納」と言
うだけのためには、あまりにも汚くて他の部分への負担が大きいように思います。

Page Faultを契機にしたPage Serverにこだわるよりも、pointer traversalを
契機にしたObject Serverの方がまだ使いやすそうな印象を受けます。

**NAME IS NULL** · 04/08/25 15:32

>>153
> ところが>>152を見て思ったのは、双方向にリンクできると
> 設計が難しく、デッドロックが発生しやすくなるのかな？ということ。

いや、それよりもPage Serverであるがゆえにロックがページ単位となり、コ
ンパイラが仮想ページの中にどのようにオブジェクトを配置するかを理解する
必要がある、ということではないでしょうか。

> おいらは階層型DBもネットワーク型DBも触ったことないんだが、
> 当時遅いと言われたらしいRDBがなぜこれだけ発展して、
> 前記２つがなぜ廃れたか、誰か知らないかな。

はるか上のほうでも書きましたが、UNIX・クライアントサーバブームが訪れた
ときに、そのプラットフォーム上でCSモデルを構築できるのがRDBしか無かっ
たからではないでしょうか。で、Oracleなんかはその流れを逃さずにホスト版
のOracleをUNIXへ移植して売り込み攻勢をかけたと。

だからOracleのコマンドラインツールはUNIXっぽくもWindowsっぽくも無くて、
なんか変な感じでしょ?(もう何年も触ってないけど)

他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。

U ◆CZtFsGiu0c · 04/08/25 17:00

>>153
ところが>>152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。

ページロックしかサポートしていないRDBMSで、一つのページに複数のテーブルの
レコードがランダムに存在している状態を想像してみてください:-)

>>155
同意します。オブジェクトモデルをデータモデルに落とすのは、それほど難しく
ありません。もちろん再帰的な構造を持つものなど、悩ましいものはありますが。
RDBがいいのは、テーブル間の物理的な関係が疎なために、アドホックな参照や
メンテナンスがやりやすいことですね。

>>157
汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
ですが。

>他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。

C/S全盛の時代より前にありましたよ。

**NAME IS NULL** · 04/08/25 17:50

>>158
> >>157
> 汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
> Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
> ですが。

探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。
http://infoboerse.doag.de/mirror/frank/faqora.htm#HIST

> C/S全盛の時代より前にありましたよ。

でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな？

トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。

U ◆CZtFsGiu0c · 04/08/25 20:13

>>159
>探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。

本当だ。メインフレームでOracle使ってるって聞いたことないんですが、
やっぱりIBMプラットフォームですかね。
＃それにしてもラリーエリソンが技術者だということを知ってる人はどの
＃くらいいるのかな?

>でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな？

ああ、Unix限定ですか。それでもTUXEDOとかその頃からあったと思いますが。
MQもあったし、DCE(ってRPCのこと?)もありましたよね。

>トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。

VB＋ODBCでRDBをサーバにしたGUIアプリケーションが容易に開発できるよう
になったのが大きいですね。で、InformixやSybaseはそれに乗り遅れた、と。

**NAME IS NULL** · 04/08/25 21:59

> 設計というよりも実装の話ですよね?

実装(制限)に合わせた設計を要求されるということある。
これは、実際のデータモデリングとは異なるスキーマ定義を
しなければいけなくなることがある、ということを意味する。

> RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
> ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
> 「left outer join」に相当するわけだし。

left outer join を使うこと自体がトリックなのである。
left outer join はポインタを辿る操作であるが、A left outer join B とは
"A から B を辿る" ことを意味する。>>151 で例示した問題では、
"伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
これは、子から親を辿っていることに他ならない。

ここで、ひとつ考えてみて欲しい。その元となる子(伝票明細)の集合は
どのようにして集めるのだろうか？伝票番号=123 を取り出したいとき、
伝票番号=123 を持つ伝票明細を取り出し、外結合によって伝票ヘッダを
辿ることになる。これは明らかに問題が前後している。伝票ヘッダを辿る前に、
伝票ヘッダの主要素である伝票番号を伝票明細は利用しなければならないのだから。

RDB の設計に慣れた人間ほど、この問題を意識することができない。
得たい結果から、無意識のうちに RDB式のスキーマ設計を行えるようように
訓練されてしまっているからだ。

この伝票問題の設計において、ルーキーが次のような愚かな設計をすることがある。
伝票 1枚あたりの明細数が最大10明細であると決めうち、伝票ヘッダに
伝票明細1行目, 伝票明細2行目, ･･･, 伝票明細10行目と子へのポインタを
持たせてしまうのだ。これは RDB の設計としては明らかに誤りである。
正規化されていないために、商品A を購入している伝票を検索することが
できなくなってしまうのだから。

しかし、この発想を頭ごなしに否定してはいけない。この発想こそ直接的モデル化なのである。
発想自体は非常に分かりやすく直感的なものである。ただ、RDB においてはスキーマで
表現できないために、「誤り」として否定せざるを得ないだけのことである。このルーキーの
設計を馬鹿にする前に、この発想を直接的にモデル化できない RDB の制限についても
考えてみてもらいたい。RDB がモデル化において完全ではないことが次第に見えてくる。

**NAME IS NULL** · 04/08/25 22:01

まだ RDB の問題を理解できていないだろうと思う。
もうひとつ例題を示そう。

私、山田太郎には複数の子供がいる。さて、山田太郎の子供を探してきて欲しい。
この世界の住人には同名の人は存在しない。RDB に慣れ親しんだ人達は、迷わず、

select 名前 from 住人 where 父親の名前 = '山田太郎' と書くだろう。

間違ってない。結果は正しい。しかし、あなたは、この正しい結果を得るために
信じられないほどの労力を使ったのだ。信じられない？簡単な作業だったって？

そんなことはない。自分自身が DBMS になったつもりで上記のクエリを噛み砕いて
実行してみて欲しい。あなたは、世界中の住人を訪ねて周り、「あなたの父親は
山田太郎ですか？」と尋ねなければならなかったのだ。これは、山田太郎の子供を
探すために、世界の住人すべてを走査しなければならないことを意味している。

もちろん、実際のデータベース実装では索引が利用されるため、全住人への
物理走査など発生しない。それは分かっている。ここで考えて欲しいのは、
概念としてどうかということだ。たとえ物理走査が発生しなかったとしても、
論理的には全件走査が行われたのである。DBMS は「全部調べた結果、山田太郎を
父親に持つ人達はこのだけです。」と結果を返すのだから。

「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
「そんなことはできない。」と、あなたは笑うだろう。世界中を旅して周ることに
なんのためらいも持たないのに、本人に聞く事はできないという。
滑稽ではないだろうか。これが現在の RDB なのである。

これに気付かない人は多い。索引によって世界中を旅して周る(のと同じ結果を得る)
など、あっという間にできてしまうからだ。時間はまったくかからない。
時間はかからないけど、世界中を旅していることは理解して欲しい。

**NAME IS NULL** · 04/08/25 22:26

>>161
> "伝票明細 left outer join 伝票ヘッダ" としか書くことができない。

なぜでしょう？

伝票番号は明細にだけ存在して、ヘッダには存在しないということでしょうか？
良く理解できないんでどんなデータ構造と参照処理をを想定しているのか、も
うちょっと詳しく教えてもらえませんか？

**NAME IS NULL** · 04/08/25 22:27

>>162
> 「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
山田太郎さんを特定するには、オブジェクト指向ではどうなるんでしょうか？

**NAME IS NULL** · 04/08/25 22:58

>>162
>まだ RDB の問題を理解できていないだろうと思う。
>もうひとつ例題を示そう。

どこに問題があるのか書いてもらわんと意味がわからんのだが。

**NAME IS NULL** · 04/08/25 23:29

>>163
もちろん記述としては、"伝票ヘッダ left outer join 伝票明細" と
書くこともできる。しかし、この記述は外部キー定義に則していない。
伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号とは、
伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。

>>164
ここでは、山田太郎をポイントする方法を問題とはしていない。
OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
たとえば、横浜市在住の40歳男性にちゃんねらDB板常駐という条件で、
山田太郎が見つかったというストーリーにしたら、満足するだろうか？
とにかく、山田太郎は見つかった。そこから子供を探したいということだ。

>>165
RDB ではモデル化が直接的でなくトリッキーな方法で実現しないといけないことがある、
というのが現在の RDB の問題である。これは、実装技術により速度的にはなんの問題もない。
だが、概念としての難解さを抱えているのである。

select 名前 from 住人 where 父親の名前 = '山田太郎'

もう一度、これを見て欲しい。実装や速度の話をしているのではない。
「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。

「山田太郎の子供を探す」という命題が「住人すべての中から山田太郎を父親に
持つ人を抽出する」としか記述できないのである。これは本質を、RDB の性質に
合わせて書き換えているということであり、可読性の低下をもたらしている、とも言える。

この RDB の性質に合わせた問い合わせの書き換えについては、可読性の低下だけでなく
誤った結果を得てしまうというミスにつながることも少なくない。このミスの発生については
また改めて名寄せに類似した問題で説明することにしよう。

**NAME IS NULL** · 04/08/26 00:00

>>166
> しかし、この記述は外部キー定義に則していない。

なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
操作における参照方向を定義したものじゃないと思ってたけど。

「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
それは参照方向の定義だ」という主張でしょうか？

> 伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号とは、
> 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。

それで良いと思うけど。OIDならそれを回避できるわけじゃないですよね？
OIDが物理アドレスに簡単に変換できるかどうかというのはまさしく「実装」
の問題ですよね？

> >>164
> OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。

だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
変だと思うけど。

> とにかく、山田太郎は見つかった。そこから子供を探したいということだ。

つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
よい、ということでしょうか？

**NAME IS NULL** · 04/08/26 00:25

>>165
>実装や速度の話をしているのではない。
>「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
>これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。

そうなの？実装されたプログラムの速度が問題なのかとおもってた…

速度が問題じゃないなら、あなたがやっかいさを指摘してるのは「関係代数」なのか。
そこまでくると話が発散しそうだな。たとえば行列演算や基礎物理が理解できないやつに
ポリゴン使った3Dゲームのプログラム任せられないのと一緒で、
関係代数のエッセンスをつかめないやつにRDB使うプログラム任せるなってことに
なってしまう。

それとも、ORマッピングなんて所詮ムリヤリな話だからオブジェクト指向の
大事なメリットを損ねるのよ、だからプログラムをOOでやるなら
DBもOOでやれよって話？

**NAME IS NULL** · 04/08/26 00:27

まちがえた >>166 ね。

**NAME IS NULL** · 04/08/26 00:45

> なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
> 操作における参照方向を定義したものじゃないと思ってたけど。

外部キー定義とは、データ走査における(推奨される)参照方向の定義である。
これに従わないものは「辿る(外部参照)」という行為ではなく横断的検索である。
なぜなら、外部キーの性質により順方向の参照は、必ず 1件の結果となるが、
逆方向の参照結果が 1件になることは稀だからである。

> 「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
> それは参照方向の定義だ」という主張でしょうか？

主張するつもりはないが事実としてそうである。伝票明細は商品への外部参照を持つ。
これは、「伝票明細から売り上げた商品を知ることができる」ことを意味する。
商品から無数に存在する伝票明細への参照というのはモデル化として、おかしい。

> > 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
> それで良いと思うけど。

「伝票明細全体から探す」ということに疑問を感じないのであれば、
私は、もうこれ以上あなたに説明するだけの言葉を持っていないということだと思う。

> だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
> 変だと思うけど。

> つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
> よい、ということでしょうか？

申し訳ないが、これらの質問の意味・意図も理解できなかった。
あなたは何をしたいのか？

**NAME IS NULL** · 04/08/26 00:59

> DBもOOでやれよって話？

これだけは否定しておいたほうがいいだろう。私はモデル化の制限について話し、
これらが実装の問題でないことを説明してきた。だが･･･今までの私の説明と矛盾するようだが、
もっとも重要なのが「実装」なのである。なぜなら、実装を差し置いて(理想的なモデル化論だけで)
システムを組み上げることはできないからである。

つまり実際に使用できる実装を考えた場合、現時点では RDB を選択するのが
もっとも良いと私自身考えている。ハンドリングが Java などの OOP であったとしても
バックエンドには、現時点で RDB を選択すべきなのである。私は OODB を推したりはしない。

ただ、いまの RDB が 100年続くとは思って欲しくない。私が指摘したように
うまくモデル化できない事象もたくさんある。これらを真面目に考えていくことは
RDB のブレークスルーになるかもしれないのだ。

**NAME IS NULL** · 04/08/26 01:13

>>170
私は167ではないけど、まぁもちついて。

167が言ってるのは…DBMSのメリットのひとつ

[特定のデータ操作からデータの内部構造を独立させることができ、
その独立性によって仕様変更に対する柔軟性が向上したり、
他のクエリに対しても同じような速度でアクセスできるという期待を持てる]

をあげてる。
特定の操作に対する最適化は、それはそれでアリだけど、
それを持ち出してきてRDB、というか関係代数が問題を含んでいる
というのはちと飛躍かと。

あと、１：Nの例を挙げてるけど、現実世界がN：Mになっててそれを
率直にモデリングしたい場合もあるわけで。関係代数のメリットって
それを中立的に表現できることじゃないの？

それから気になったこと。
やろうと思えば親１：子N関係でも親から子へ、子の数に関係なくリンク張れるがな。
C言語なんかではN分木を、「長男と弟へのリンク」の２分木として実装するでしょ。
それと一緒。伝票ヘッダは商品１へのリンクだけ持ってて、商品１が
商品２へのリンクを持ってればすむ。
あなたならディレクトリ構造みたいな木をどうやってコーディングするのさ？

そんでそれは、関係代数マンセーな視点からは「最適化に含まれるので
別議論である」ってこと。

**NAME IS NULL** · 04/08/26 07:12

おはよう、諸君。
あなたたちは、まだ理解が追いついていないようだ。
もうちょっと説明してあげたいこともあったのだが、的外れな質問で
話が遮られるばかりなので、ここでの説明はこれで打ち止めとしよう。
非常に残念なことである。

あなたたちには、これからももっとがんばってもらいたいものである。

**NAME IS NULL** · 04/08/26 16:55

>>173
あまり論点が明確化されてなくて探りを入れることになったので、質問が的を
はずしていたかもしれないのはしょうがないですね。
＃全くの他人とは、あまり議論されたことが無いのかな？

私は結局論点にしたいのがモデルなのか、DB利用者にとっての実装か、DBMS自
体の実装か、利用する上でのシンタックスなのか分からずじまいでした。

もう止めるということなので残念です。どなたか>>170にあった「外部キー定
義とは、データ走査における(推奨される)参照方向の定義」というのが分かる
Webサイトか何か知りませんか？
＃もう今の環境じゃDB関連の書籍が手元に無い、、、

私の頭の中じゃ、外部キー定義はレコードが参照して整合性を保つためのもの
で、アプリがその参照を参考にしながら逆方向に辿るのは全然OKだと理解して
た。

**NAME IS NULL** · 04/08/26 19:31

外部参照制約に方向はあるよね。
逆向きに使っちゃいけないのかどうかは知らんけど。
スキーマとして依存関係を記しているというのもうなずける。
話の意味は良くわかんないんだけど、読み物として面白いから
山田太郎先生には返ってきて欲しいぞ。

**NAME IS NULL** · 04/08/26 22:28

OODBにしてもXMLDBにしても、そういう一風変わったモノは
DQNに取り憑かれ易いよなぁ。

**NAME IS NULL** · 04/09/01 00:39

あそれ～♪
D どんな
Q クエリも
N ぬるぽで返す～
ときたもんだ
　 ∧＿∧
　（　´∀｀）＜ぬるぽ

U ◆CZtFsGiu0c · 04/09/03 12:44

最近知ったのですが、ObjectCacheってバックエンドがRDBでも使えるのですね。
分散環境で高速参照が必要なところで使ってみると面白いかも。

**NAME IS NULL** · 04/09/21 23:58:35

遅レスだが
>>178 は @it の記事のことですかな？
私はいまODB勉強中なのですが、
確かに面白いかも…

しかし、ううむ…。あの記事、なんか論調として
・RDBを扱える技術者は豊富
・RDBは壊れたときのリカバリなど実績がある
・間にはさむキャッシュとしてObjectCacheをつかうと速くてｳﾏｰ
というように読めたのだけど、それって、
RDBでスピードが出なかったときの
最適化の選択肢なのかな？いやまてよ、
ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。

ObjectCache使ったアプリ書いたひといる？
アプリの書き方変わらんの？

**NAME IS NULL** · 04/09/22 06:52:16

最近のシステムではRDBアクセスをEJBで隠蔽しているものが結構あると認識していますが、
これって、EJB-RDBひとまとめにしてDBと考えると、
「EJB+RDB=OODB!! カモンOODB!!」
などと思うのですよ。
本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、
データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
何かないでつか。

**NAME IS NULL** · 04/09/22 13:24:32

age

**NAME IS NULL** · 04/09/22 14:45:41

>>180
> これって、EJB-RDBひとまとめにしてDBと考えると、
> 「EJB+RDB=OODB!! カモンOODB!!」
> などと思うのですよ。

RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
ないでしょうか。

> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
> 何かないでつか。

MATISSEが多少近いかもしれません。meta-schemaをいじれるようになっている
らしいので。

しかし、ユーザに提供しているインタフェースと、DBMS内のモデル・検索処理・
トランザクション管理・排他制御・ディスクページ内レイアウト・ロギングが
密接に関連しているので、完全にフリーにするのは難しいと思います。

RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
合には大抵ライブラリやラッパーをかぶせて実現しています。

無理やり実現しようとすると結局ファイルシステムと大差ないものになってし
まう気がします。

**180** · 04/09/23 01:09:56

>>182
レスどうもです。
うーん、考えがまとまってないので少しだけ。
>RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
>する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
>が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
>ないでしょうか。
・・・中略・・・
>RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
>合には大抵ライブラリやラッパーをかぶせて実現しています。
ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
実のところ、既存のoodbは適当な記事に書かれている程度しか知りませんが、
オブジェクト指向のメリットの一つは、データモデルをカプセル化できること
の筈。なら、そのようなDBがあればべんりかな、と。裏側で動いているRDB
のデータモデルも、裏側で検索やっているBLAST*も隠して、同じように／横断
的にアクセスできるとけっこう有り難い・・・。

*blast うちらはcgiでやることが多いのですよ、これ。以下参考；
http://www.ddbj.nig.ac.jp/search/archives/homology_doc-j.html

**NAME IS NULL** · 04/09/23 14:15:13

>>180
> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
フリーって何のことか補足ｷﾎﾞﾝﾇ

U ◆CZtFsGiu0c · 04/09/23 14:30:48

>>179
>@it の記事のことですかな？

そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック
エンドに使えるとは知らずスルーしていました。

>ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。

まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。
ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで
O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー
マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決
できるんじゃないかな、と思います。

**180** · 04/09/23 14:58:35

>>184
交換可。データモデル等からある程度自由になりたいの。
プラッガブルとか書いた方が良かったかな。

**NAME IS NULL** · 04/09/24 17:47:46

>>183

EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。

> ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
> oo的にはInterfaceが一緒であればいいかな、と思ったのですが。

もともとDBMSの類はデータを公開して共有しよう、というところから生まれて
いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま
ま当てはまらないところもあると思います。

カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、
いったんDBに格納した過去のデータは簡単には変更できないという違いもあり
ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど)

アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
利かもしれません。

アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、

・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース
をどうやって定義するのか。
・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部
分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。

辺りが悩ましそうです。考察するのは面白そうだけど

パッケージや製品として世の中に出す場合には、システム非依存にしなければ
ならないところも難しい点だと思います。
逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。
(それも特定の業務「モデル」に縛られることにはなるけど)

＃勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな？SAPもそうだっけ？

**180** · 04/09/25 04:25:00

あう。凄く誤解させてしまったかも。スマソ。
>>187
>アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
>えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
>利かもしれません。
入れ替える、というのが不適切な表現だったようです。
想定している応用はこんな感じです。
1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。
2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。
3.xmlなグラフデータも検索したい。
4.検索結果をオブジェクトとして受け取りたい。
ですので、入れ替えるというよりは組み合わせて使うような。

それだとデータモデル横断的な検索とかできないから何かないか、
というのが180の後半です。
やっぱり
182>ライブラリやラッパーをかぶせて実現
とかObjectCache'とかじゃないと余計悩ましそうですね。

**NAME IS NULL** · 04/09/26 11:38:40

とりあえず現在ObjectStoreを使っているけど、全然メリットを感じない。
クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ
ならないんじゃ実運用に耐えない。

ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。

またRDBであれば、他システムとの連携が簡単（ODBC,EAIなど）だが、インタフェースが
独自のODBではそれも難しい。

ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や
保守運用時には全然メリットを感じない。

ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。

しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。

分散キャッシュでのスケールアウトもOracleのRACの方がまし。

ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは
全く感じられない。

U ◆CZtFsGiu0c · 04/09/26 19:33:12

>>189
(今までの書き込みを見てもらえばわかるけど)大半は同意。

>ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。

サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?

>ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。

いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために
クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では
OODBを積極的に使うほどのメリットには思えないけどね。

>しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。

キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
クラスタへの配置とか?

**NAME IS NULL** · 04/09/26 21:33:13

>サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
>メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?

クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
特に最近はＤＢサーバ上のストアドが高級言語になりつつあるから、余計ＯＤＢの
メリットが少なくなる。

ＣＰＵ技術が、これからマルチチップ、マルチスレッド＋仮想化進むので、
わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、
運用保守費が増加するだけと思います。

>キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
>クラスタへの配置とか?
クライアントキャッシュのサイズなどです。
確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。
キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。

ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、
それはRACでのスケールアウトでも達成可能。
でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。

個人的には、SQLServer2005のようなストアドの高級言語化の方が、
ODBよりも良いと思われる。
ChacheのようなアプローチもObjectStoreよりかは良いですね。

いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より
値検索の方が多いので、ODBの出番はない。

**NAME IS NULL** · 04/09/27 17:56:40

>>188
> それだとデータモデル横断的な検索とかできないから何かないか、
> というのが180の後半です。

なるほど。
昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい
だけど、頓挫したのか普及しなかったのか、、、

今はそれ以上にいろんな検索がありえるし。
全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、
後はアプリケーションでがんばってね、とか。

結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。

・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定
・インタフェースはOODBを参考に
・引数等で各バックエンド固有の機能を記述することは極力避ける

というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事
はしていないなw
.NETとかは一応この方向を目指してるんだっけ？

**NAME IS NULL** · 04/09/27 18:18:48

>>191
ほぼ全面的に同意ですが、

> クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
> ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。

性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思
えないです。

また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの
なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。

OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ
に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛
いですね。

HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し
かないですし。

ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作
したんだろう？

**NAME IS NULL** · 04/09/27 22:21:11

オブジェクト指向でシステムを設計すると、多態性のあるオブジェクト群をひ
とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく
出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする
と１インスタンス＝１レコードといった単純な格納の仕方が通用しなくなる
ので、かなり頭をひねらなくてはならなくなると思います。

そういったことを考えると、ODBといったものの方が自然に扱えていいと思う
のですがいかがですか。

**NAME IS NULL** · 04/09/28 13:23:11

>>194
ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ
クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に
そうだし、他のOODBもそれを志向しています。

そのためプログラミングは便利になるかもしれないけど、システムを稼動させ
たときの運用などにしわ寄せがよってしまいます。

どちらがクリティカルかといえば、動かしたときの方だと思います。

**NAME IS NULL** · 04/09/28 15:32:32

>>195 うーん、そうなんですか。

- オブジェクトをアプリケーションから透過的に永続化したい

というニーズと

- オブジェクト指向設計に即したデータストアのインフラが欲しい

というニーズは似て非なるものですよね。
現行の製品はもしかすると前者からスタートしているのでしょうか。
だとすればあまり魅力を感じません。
むしろ欲しいのは後者です。今後に期待したいですね。

**NAME IS NULL** · 04/09/28 17:25:43

>>196
ZopeのZODBなんかは、前のやつそのものって感じですね。

**NAME IS NULL** · 04/09/28 18:00:58

>>197
Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの
ように扱える反面、Pythonからしかアクセスできないみたいですね。

データベースに格納したオブジェクトが、例えばCORBAのような
汎用のインターフェースを通じてリモートオブジェクトとして
アクセスできるような製品はないんでしょうか。

**NAME IS NULL** · 04/09/28 19:30:14

>>198
CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し
てCORBA側が対応したのかな？

だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく
知りません。

そもそもPOS自体が企画倒れになったらしいから、あまり（CORBAとしては)力
を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか
な。分散トランザクションもややこしいし。

**NAME IS NULL** · 04/10/12 15:42:35

>>199
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。

POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。

**NAME IS NULL** · 04/10/13 17:13:49

>>200
> CORBA自体が下火だからでしょうか。

結局水平分散はコンセプトとしては美しいけど、方式設計や運用設計が難しかっ
たんですかね。

だからといってEJBや.NETの世界に行っても、ヘテロジニアスなストレージレ
イヤの水平分散・統合が簡単になることもなさそうと思ってるんですけど、実
際どんな感じなんでしょう?＞使っている方。

Entity BeanやEJBの分散トランザクション管理機能(DBMSにdispatchするだけ
じゃなくて)がここまで進化した、というような話はあるでしょうか?

**NAME IS NULL** · 04/11/25 18:55:24

ttp://www.atmarkit.co.jp/fdb/single/01_rfid_database/rfid_database01.html
RFID、ECサイトに求められるデータベース性能とは？

>バックエンドのRDBMSはそのままに、
>フロントエンドのデータ・キャッシングに「ObjectStore 注」のファミリ製品であるObjectCacheを導入することで、
>Linuxマシン上で稼働する4つのObjectCacheインスタンスにリプレイスでき、コストを大幅に削減できました

>同期処理時間は12時間から1分以内に改善され、応答速度も向上しています。

理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？

**NAME IS NULL** · 04/11/26 11:10:13

>>202
> 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？

使っているのはOODBじゃなくて、キャッシュでは?

機能を想像してみると、RDBのデータをどの単位か分からないけれどフロント
エンドマシンにキャッシュして、OOPLから透過にアクセスできる、というもの
じゃないでしょうか。
RDBMSのデータキャッシュページと連動させていたら結構すごい機能だと思う
けど、やってるのかな。

ディスクじゃなくてメモリにすれば、そりゃ速くなるでしょうね。

「同期処理」とか注文処理のトランザクションの内容やタイミングが分からな
いから、どの程度キャッシュの賢さが効いているのか分からないけど。もとも
との設計がタコだったのかもしれないし。

数年前のシステムを公開しているのだと仮定すると、当時と比べればIAサーバ
の性能も上がってコストも安くなってるだろうし、Linuxも最近ようやく使い
物になってきたし。この辺はObjectCacheとは全然関係ないですね。

ところで、ObjectStoreっていつの間にか買収されてたんですね。3年ぐらい前
はXMLブームに乗って「今後はXMLに特化した製品・会社になる」と宣言してい
たような気がしたんですが、最近はEC・リアルタイムに特化なんでしょうか。

**NAME IS NULL** · 04/12/02 00:53:48

Cach？を使ってみたいのに、手早くMySQLに逃げてしまう漏れ。
自宅ではMacOSXなので動かん。どうしょ。

**NAME IS NULL** · 04/12/15 00:08:43

>>203
想像のとおりで、このアイデアにはOODBの研究者
ベンチャー(ObjectStoreなど）が興奮したわけですね。

しかし、reading in dababase systemsの編者による解説部分や、
Of Objects and Databases: A Decade of Turmoil by dewittを
読めばわかるが、OODBは、CADなどニッチな市場しか獲得できず、
期待していた市場は、ORDBに取って代わられたということ。

キャッシュコーヒーレンスや、ロックは、callback lockingなど
いろいろ工夫したが、典型的なOLTPアプリでは、性能が出ない。

OODBの性能の肝は、キャッシュ制御にあるが、この辺の研究成果はRDBにも適用
できるわけで。

OODBの大きな利点に、ホスト言語と問い合わせ言語間のインピーダンスミスマッチと
複雑なデータ構造を処理できる点にあるが、昨今の流れでは、dewitt氏も指摘したが、
ORマッピングが商用では主流、今後もOODBはニッチな市場しかないじゃないかな。

**NAME IS NULL** · 04/12/15 23:12:48

質問なんですが、OODBに格納されているデータを覗くには、とにもかくにもプログラムインターフェイスを介さないと見れないのでしょうか？
OracleのSQL*Plusとか、それこそAccessみたいな感じのビューワってあるんでしょうか？
（簡単にデータの格納状態がエビデンスとして見れるツールがないと開発には使えない）

まぁ仮にそういうツールがあったとしても、おそらくそういったビューワでオブジェクトを参照できるようにするためには
そのオブジェクトがOODB製品が提供する独自のツール表示用interfaceを実装する必要があるとか、
そういう仕組みがあるのでしょうけど。

**NAME IS NULL** · 04/12/15 23:14:53

あと>>32にも書いてあるが、クロス言語を実現できる製品はあるのでしょうか？
例えばOODBの提供するinterdaceを実装することで、複数の言語への（ある程度の）マッピングをOODB側が
自動的に行ってくれるとか。
そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。

U ◆CZtFsGiu0c · 04/12/16 12:14:07

>>205
RDBで分散キャッシュができれば、現状のOODBの意義はほとんどないと思います。

>>206
ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
想定されているのなら、そういうものはないでしょう。

>>207
Objectivityは言語非依存のようです。また、Cacheもそうですよね。

**NAME IS NULL** · 04/12/17 01:07:40

OODBってさ、問い合わせ方式は、やっぱり所謂Dictionaryのように、一意のキー（GUIDのような）で
関連付けたりするの？
あと関係型（RDB）のSQLや階層型（例えばXMLDB）のXPathに相当する問い合わせ言語がないというのは
むしろOODB的にはデメリットだと思うんだけど。
条件付きの検索というのは業務では必須だし、そもそもユニークIDだけで一意にモデリングできるものって
世の中にはあまりない。

検索機能がないのって、例えば履歴書10000枚をキングファイル10冊目にまとめて前に置かれて、
「このキングファイルの中の履歴書にはすべて一意の番号がふってある。
　目の前に置いてあるからわざわざ取りに行く必要はない。
　さあこの中から○×の条件にあった人材を捜せ」
といわれているのと同じような気がする。

ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。

**NAME IS NULL** · 04/12/20 19:34:13

>>209
> ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
> もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。

ODMGは企画倒れになったけど、少なくともVersantにはQuery Languageが有りました。
VersantにはSQLラッパーみたいなのが有って、ROマッピングも出来たように覚えてます。
（5～6年前の記憶）
おまじないカラムを使ってJOINする命令を投げるとと、DBMSではpointer
chasingしてくれるという面白いインタフェースです。

もともとOODBには「Query Languageが欲しければ自分でいくらでも好きなよう
にプログラムすれば良い」という発想が最初にあったように思います。

でもそれじゃ使いづらいから各社とも付けてますが。
さすがにアーキテクチャ上一番なじみにくそうなObjectStoreでも属性値を指
定して全件検索することぐらい出来るんじゃないかな。

**NAME IS NULL** · 04/12/20 19:42:09

>>208
> ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
> の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
> 想定されているのなら、そういうものはないでしょう。

RDBの「汎用ツール」にしたって、ユーザに公開しているプログラミング用の
インタフェースを使って出来ているでしょうから、OODBが特に使いにくいとい
うこともないのでは。

あ、RDBだとSQL*Plus見たいなものを自分で作ろうと思えば作れるけど、OODB
だと相当面倒なことになるんでしょうか。

「Inspector」を使うためには開発したクラス定義ファイルを読み込ませてや
らないといけなくて、Inspectorの中ではかなり高度なことをやっているのかな。

**NAME IS NULL** · 04/12/20 19:57:25

>>207
> そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
> 後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。

こうした、「要するにプログラムの中の変数を保存すればよいんでしょ？」と
いう発想が、そもそもOODBや一部オブジェクト指向技術者の間違いだと思いま
す。
＃207さん失礼。

もともと「データ」はコンピュータを使う前から現実に存在していて、それを
コンピュータでどうやって管理するか、という考えからDBMSが出来ていると思
います。

少なくともトランザクション管理や排他制御などを備えたDBMSは、暗黙的にそ
うしたことを想定しています。

その点でコンピュータが出来てから発生した画像ファイルとか文書ファイルを
「ファイル→名前をつけて保存」するのとは全く違います。

これは「プログラミング」のみに着目して、プログラムを実行してどうするの
かを全く忘れ去ったために起こった履き違えだと思います。

>>205に出てくる「インピーダンスミスマッチ」も確かに存在するのですが、「インピーダンス
ミスマッチ」を理由に履き違えによる本末転倒が広まってしまった気がします。

＃OODBがあんまり好きじゃないから、ひどい言い方になってるなぁ、、、

**NAME IS NULL** · 04/12/28 11:16:29

>>212
オブジェクトの永続化は変数の保存とかファイルのセーブなどとは
違う水準の発想だと思うけど。

「オブジェクト」はコンピュータを使う前から現実に存在している
もので、オブジェクト指向設計はそれをコンピュータでどうやって
管理するか、という考えだし。:-)

**NAME IS NULL** · 04/12/28 18:55:28

>>213
＞「オブジェクト」はコンピュータを使う前から現実に存在している
いやーそういう原理主義は今は流行ってないよ。

**NAME IS NULL** · 05/01/07 10:00:37

でもデータ中心主義者のいう「エンティティ」と
オブジェクト指向主義者のいう「オブジェクト」って
似たり寄ったりの概念だよね

**NAME IS NULL** · 05/01/07 20:25:08

>>213
コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。

私にはそうした意味の「オブジェクト」とは非常に抽象化された概念で、「○
○すること」「○○するもの」と呼べるもの全般を指しているように思えます。

それはDBMSを使った実装とか開発等とは全然別のレイヤの概念で、それに無理
矢理「オブジェクト」と同じ呼称を付けて一緒くたにしているんじゃないでしょ
うか。

「オブジェクトの永続化」と「変数の保存」がどのように違う水準で議論
･考察・活用されているのか教えてください。

＃クレクレ君ですいませんが。

**NAME IS NULL** · 05/01/12 22:36:21

http://www.db4o.com/

ｷﾀ━(ﾟ∀ﾟ)━!

**NAME IS NULL** · 05/01/13 18:37:36

組込み用データベース？

**NAME IS NULL** · 05/01/19 04:16:16

OODBって問い合わせ言語は何使うの？
SQLじゃないよね？

**NAME IS NULL** · 05/01/19 10:25:43

sqlも限定的に使えるのもあったんじゃなかったかな。
cacheかな。何せ使った事がないもんですみません。

U ◆CZtFsGiu0c · 05/01/19 16:12:01

>>219
OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。

**NAME IS NULL** · 05/01/19 18:26:09

ODBってJAVAのbeanをそのままDBに格納するのですか？
格納するときはいいけど、selectとかしたらどうなるの？
beanの型でデータが返ってくるのですか？
（だとしたら、joinとかしたらどうなるのだろう･･･
新規のbean型を動的に生成するのだろうか？）

**NAME IS NULL** · 05/02/19 21:10:21

Cach?

**失敗した…** · 05/02/19 21:11:26

Caché

**NAME IS NULL** · 05/02/19 22:37:33

ODBとオブジェクト指向言語の関係が今ひとつわからない。
要するにオブジェクトを永続させたいのか。
データベースの主張するところはとどのつまりデータの独立だった。
ここのところはどうなるか。それで唐突に思い出したのだが、
IBMシステム38がサンノゼ研究所で1970年代に開発された時、
最大の課題は「停電」だった、と言う話。
このメモリー(プログラム)とデータベースを一体に見ようとした
システムでの課題はデータの永続性だったということ。

**225訂正** · 05/02/19 22:42:32

>このメモリー(プログラム)と → このメモリーと

**NAME IS NULL** · 05/02/21 15:29:18

>>225
(偏見に満ちたレスです。)

ODBとOOPLを考えるときに、アーキテクチャ全体がどうなっているかとか、
システムがどういう風に稼動・運用・活用されるのかということを考えてはい
けません。

目の前のエディタに表示されている作成中プログラムのコードだけに着目しま
しょう。オブジェクト指向で楽しくプログラミングしているのにSQLとか変な
ものが混ざってきて嫌ですよね。

そこで全てを｢オブジェクト｣にしてしまえば解決してしまいます。

SQLなんてコンピュータの都合で産まれたもので、それに比べればオブジェク
トというこの世に昔から存在しているものを活用すれば、全てがうまくいきます。

「データの独立性が云々」なんて考える必要はありません。
だってそもそもやりたいことはプログラミングなんだし。プログラムのおまけ
のデータなんて、適当にディスクへ吐き出しとけばいいんです。

仕事はコンパイルまでで終わりだし、論文や文献の実証実験にもなって一石二鳥ですね。

＃一応「皮肉」で書いたつもり。OODBの利点を熱く語る人がいないとネタになっちゃうなぁ。

**NAME IS NULL** · 05/02/21 17:13:33

>>227 素敵なレスです。皮肉でなく。でもここだけは納得できません。
>SQLなんてコンピュータの都合で産まれたもので
SQLは論理式(まがい)です。オブジェクトを認識できるものが
論理から超越していることはあり得ません。
あなたの文章はしっかりしていますし、十分に論理的です。

**NAME IS NULL** · 05/02/21 23:57:01

プログラムなんてデータのおまけ

**NAME IS NULL** · 05/02/22 01:00:53

ミドルウエアの適用というのは多分にイマジネーションの世界だと思うんだけど、
やっぱり現時点では具体的に使えそうな業務というか適応分野があまり見当たらないよ。
（別部署のシステムでGemStone＋Smalltalkというシステムが1つあるけど、必然性を感じない）

それこそかつてのJavlinのようなEJBキャッシュみたいなニッチなところ（業務そのものの
データではなく、極めて基盤的なところ）にしか入り込めないという印象。

逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。

**NAME IS NULL** · 05/02/22 18:01:16

>>225 >>227 >>228 >>229
オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。
SQLは集合の性質を記述するもの(内包的な定義)。

**NAME IS NULL** · 05/02/22 21:17:42

もっと続けて、ハイ！！

**NAME IS NULL** · 05/02/23 01:22:10

>>225 商用システムでオブジェクトという概念を最初に持ち出したのが
システム38ですね。良かれ悪しかれ興味深いマシンでした。

**NAME IS NULL** · 05/02/26 23:32:58

いろいろ異論はあろうが、ざっくりと「オブジェクト＝データ＋手続き」と定義する。

データについては、表現方法を妥当なレベルで共通にできる。
しかし手続きは、言語や処理系によってその表現は異なる。なかなか共通させることはできない。

「オブジェクトの表現形式」を標準化し、それをいろんな処理系からアクセスできるようにする作業が必要になる。
で、それは技術的には可能だ。
だが実際問題としてそこまでやる必要性が薄い。

単にオブジェクトデータベースを使うだけならいつでもできるが、
広い普及はまだまだ無理な状況にある。

**NAME IS NULL** · 05/02/28 02:20:11

BFS1.0やWinFSってRDBだよねぇ。OODBがFSになるのはいつの日か・・・

**NAME IS NULL** · 05/03/02 00:32:49

OODBなファイルシステムっていまいちイメージがつかめんが、
Newtonのsoupとか、BTRONみたいなものかな？

**NAME IS NULL** · 05/03/20 23:15:49

>> 234
データはオブジェクトごとに異なりますが、手続きは変わりませんよね。
オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。
また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、
むしろ手続きは永続化対象外でであるべきかと思います。

データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル
モデルに変換するひつようがないのであれば価値があると感じます。

**NAME IS NULL** · 2005/04/02(土) 11:19:43

RDBMSで現実的なシステムを組むために
ストアドとかトリガみたいな機能が必要になったことが、
データと手続きが不可分であることを表していると思うのだが

**NAME IS NULL** · 2005/04/04(月) 17:07:52

久々に書きこもう。

>>238
実装(プログラミング)のためにはそうした方が便利という面はあると思う。

だけど実装のために必要になったデータ(ループ変数とかフラグとか関数間受
け渡しための変数とか)と、業務で必要なデータ(顧客名とかIDとか単価とか)
は概念上別なものとして認識するのが自然だと思うけど。

OOな人は何故か「とにかくプログラム上は一緒なんだから」という考えのよう
な気がして不思議。

OOな人の目的ってやっぱりプログラミング?

U ◆CZtFsGiu0c · 2005/04/05(火) 16:06:19

>>239
よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに
違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって
OODBを使いたがるとは限らないよ。

**NAME IS NULL** · 2005/04/05(火) 17:28:25

>>240
ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

で、私は「永続化すべきデータに違いはない」とまるっきり区別しない事に、
違和感を感じていると書いたつもりです。
(この引用の仕方はU ◆CZtFsGiu0cさんの意図とは違っているかもしれません)

あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。

このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん
ですが。

U ◆CZtFsGiu0c · 2005/04/05(火) 17:57:39

>>241
>ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。

>あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。

これは、「インピーダンス・ミスマッチ」の一言につきると思います。
設計したモデルをデータストアの都合で崩さなければならない、ということに
不満がありますね。

それから細かいことを言うと、データストアがOODBでない場合はカプセル化を
破るか永続化するデータを持つクラスが永続化の手段を知っている必要がある
ので、それはあまり歓迎できないと言うのはあります。

>しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。

合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
壁があるからなんとかできないか、と考えるのは自然ではないですか?

**NAME IS NULL** · 2005/04/05(火) 18:45:37

>>242
> よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
> すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。

データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。

> 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
> 壁があるからなんとかできないか、と考えるのは自然ではないですか?

プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。

「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。

U ◆CZtFsGiu0c · 2005/04/05(火) 19:28:39

>>243
>データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。

うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
当たり前だと思うけど、具体的にはどういうことですか?

>プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。

「顧客との意思疎通」はともかく、保守・運用やアドホックなデータ検索に
関しては今のOODBはダメダメですよ。それに関する認識はここにもさんざん
書きました。だからこそ、ObjectCacheやCacheに期待するところがあるん
ですけどね。

>「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。

もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
ことしか考えてないってことないですか? プログラムの保守についてはどう
思ってますか? データベースはシステムの一部にしか過ぎないんですよ。

**NAME IS NULL** · 2005/04/06(水) 15:26:15

>>244
> うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
> 当たり前だと思うけど、具体的にはどういうことですか?

>>239で書いたようなことです。
「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。

> もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
> ことしか考えてないってことないですか? プログラムの保守についてはどう
> 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。

保守では有りませんが、DBMSの販売に昔かかわっていた者です。

DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。

・1つのDBに複数のプログラムがアクセスする場合が非常に多いこと
・システムの稼動に従ってデータ資産が増えていくが、その構造は簡単には変えられないこと
・CPUの速度よりもディスクの速度の方が圧倒的に遅いこと

プログラムだってシステムの一部に過ぎません。しかし「『一部』同士だから
検討の優先順位は同等だ」ということにはならないでしょう。
(無論個別の事情によってはいろいろと程度が変わってくると思いますが)

以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと
思います。

U ◆CZtFsGiu0c · 2005/04/06(水) 20:17:50

>>245
>「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。

そういうことですか。実装上必要な揮発性のデータを永続化するなんて
ありえない、というか「データと手続きが不可分」と言う言葉を曲解してる
ように思います。

>DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。

特に反対することはないんですが、やはり誤解されていると思います。
OOでやってもエンティティはフローズンスポットになるのでそんなに
変更は入りませんし、既存のシステムは当然考慮しますよ。

**NAME IS NULL** · 2005/04/07(木) 11:33:07

つかってはみたが・・・

なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・
まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・

**NAME IS NULL** · 2005/09/17(土) 05:08:39

OQLの話題ってここ？

なんかオレ様の知らないうちにオブジェクトDBシステム用の
クエリ言語が標準化されてますた(・へ・)
http://www.odmg.org/

日本語の情報元知ってるひといたらキボンヌ

この辺も
「LDP」
http://lambda.uta.edu/lambda-DB/manual/

「出世魚」
http://www.db.is.kyushu-u.ac.jp/fish/expl/summary.html

あとFastDB試してみたらなかなか使いやすかった。
でも誰も使ってない予感

**NAME IS NULL** · 2005/09/19(月) 07:51:19

で、複雑で大量の事象と空間をシミュレーションするのに
今現在はどの組み合わせのシステムがベストなの？

**NAME IS NULL** · 2005/09/19(月) 07:55:19

多種多様のドキュメントを管理するには何がベスト？
業務処理するには何がベスト？

**NAME IS NULL** · 2005/10/10(月) 01:31:00

ObjectStoreは，かつてのOO指向のイメージからリアルタイムデータ処理へと変貌した。

**NAME IS NULL** · 2005/11/13(日) 10:27:14

たとえば「注文」オブジェクトがあるとする。

注文番号
注文先
商品
単価
個数
消費税額

みたいなオブジェクトだとして。RDBMS だと、注文先番号や商品番号で
マスタとリレーションするよね。

O/R マッピングだと、マスタとジョインした結果を格納する、ってことができて、
RDBMS におけるメリット（マスタに変更があった場合、オブジェクトにもその
変更が反映できる）を受けられる。

OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに
変更があったらどうするんだろう？

**NAME IS NULL** · 2005/11/13(日) 17:50:39

マスタデータを表すオブジェクトを更新するだけじゃないの？

注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト

**NAME IS NULL** · 2005/11/13(日) 18:45:27

ということは、注文オブジェクトの方には、商品マスタオブジェクトのキーを保持
するってこと？

注文番号
注文先キー
商品キー
単価
個数
消費税額

って感じ？これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。