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

OODB - オブジェクト指向データベース (311ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

84: NAME IS NULL [age] 04/07/16 12:04 ID:???

>>83
> 昔、Objectivityを使ってました。
> 複雑な構造を持つデータと、頻繁なデータの入れ替わりには
> ODBMSしかないのでは。
> 速度がそもそもORDBMSと違います。

ここは、キーボードから打ち込む文法の問題なのか、それが実行されるときの
アーキテクチャの問題なのかが一緒になっている気がするので分けて考えたい
です。

> イリジウム衛星の軌道制御にも使われていたらしい。

イリジウム自体が尻つぼみだったけど、当時盛んに宣伝してましたね。総容量
1ペタバイトとうたっていたのはこのプロジェクトでしたっけ?

> DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
> ちなみに、名前でオブジェクトを関連づけたりできます。

そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
てくれるんじゃないでしょうか。

> そもそも、DBのクラスライブラリーに強力なコレクション・クラスがあるので
> その検索メソッドを呼び出すなり、そのクラスを使用して強力なコレクション・クラスを作れば
> SQLみたいに、文を生成する必要はないです。

自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。

「DBMS」という製品パッケージとして成立されるには、当然未知ユーザの未知
の使用方法に応えられるようにしなければならないわけで、その点でRDBの方
が柔軟性が高いように思えます。OODBが自分のソリューションに適合している
かどうかを判断するためには、かなり深いところまで調査する必要があるので
はないでしょうか。実際に記述することになるコードがあらかじめ分かってい
るとか、データへのアクセス統計を把握してそれとOODB内部の動作を照らし合
わせるとか。

どうもOODBが焦点をあてているのは、それまでのDBMSと比べるとシステム全体
の中でのレイヤが1段低いところにあるような気がします。

ちなみにSQLの文法が素晴らしいといっている人は、RDB好きの人の中にもいな
かったと思います。伝道師だったC.J.Dateでさえ文句を言いまくってたみたいだし。

もともとE.F.Coddがリレーショナル代数に基づいたインタフェースを提案した
けど、難しすぎて誰も使おうとしなかったらしい。

今のSQL文法はオペレータがad-hocにリクエストを実行するために、無理に平
文に似せようとして汚くなってるんでしょうね。COBOL開発のバックログに登
録するより端末からSQLをたたいた方が圧倒的に便利だし。

プログラムから呼び出す方法を考えるときに、未知の不定個のデータを扱う良
い方法が無いこともあって、SQLをそのまま埋め込んでループでまわすなんて
いう方法に落ち着いちゃったんでしょう。
埋め込みSQLとは別にCall Level Interfaceもあるけど結局SQLを使いまくるこ
とは変わらなくなっちゃったし。

http://mevius.5ch.net/test/read.cgi/db/1057157392/84

86: NAME IS NULL [age] 04/07/20 15:03 ID:???

>>85
少し話題が他の方向へ行きましたが。

> そういうのがパッケージとして用意されていれば問題ない気がする。
<snip>
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。

そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
るメリットはどの辺にありそうでしょうか。

> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。

List, Map, Iteratorそのほかが使えればオブジェクト指向的だと考えてよい
んでしょうか。（この辺の判断基準は良く分かりません）

本題から離れた興味ですが、1回のQuery結果件数が多数になった場合、RDBで
はResultの受け取りをStreamingすることになりますが、ORマッピングツール
(やOODB)でも同様の動作になるんでしょうか。
＃Listのノードを先へたどるときに、｢未取得｣と「最後」の2種類のステータスがあるとか。
それとも全結果が確定してからList等をクライアントで受け取ることになるのでしょうか。

> ループで回すって言うなら、RDBに関係なくCOBOLでもそうじゃないのかな。

COBOLを実際に触ったことが無いから想像ですが、CODASYLにアクセスするとき
はオンライン中はIDによるレコードアクセスでOLTP、オフライン中はバッチ処
理で全件検索というイメージを持ってました。「全件検索」するときにも
COBOLではループしてるんでしょうけど、RDB的なset-at-a-timeなインタフェー
スとはちょっと意味合いが代わってくるのかなと思います。

で、OODBを賛美する人がrecord-at-a-timeなインタフェースだけを取り上げて
いるのが以前(半年前w)の不満点でした。

＃なんか質問ばっかだな。

http://mevius.5ch.net/test/read.cgi/db/1057157392/86

87: 85 [sage] 04/07/20 22:40 ID:???

>>86

あんまり詳しくないんですが、

>  そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
>  クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
>  るメリットはどの辺にありそうでしょうか。

重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。

あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。

個人的には、RDBに限界を感じてますね。RDBはデータ構造が２次元ですが、階層的に持ちたいって思う事が
多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。
だからオブジェクトとかXMLとかがそのまま格納できりゃあいいんですが、現実問題として考えると・・・

>  > ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
>  > してくれるから、そのままオブジェクト指向として使える。
>  List, Map, Iteratorそのほかが使えればオブジェクト指向的だと考えてよい
>  んでしょうか。（この辺の判断基準は良く分かりません）

んー。違いますね。それはまた別問題ですね。
Listに格納されているクラスがオブジェクト指向設計されているかどうかは別の話でしょう。

項目５０個あるからセットするコードを５０行書いてとか自分でBeanをnewしてなんて書かなくても、今のO/R
マッピングツールの中にはそういうのを自動で勝手にやってくれて、Listで返してくれるものもあるよんって意味でかきました。
（マッピングツールが全部そうってわけじゃないけど。）

ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。

>  本題から離れた興味ですが、1回のQuery結果件数が多数になった場合、RDBで
>  はResultの受け取りをStreamingすることになりますが、ORマッピングツール
>  (やOODB)でも同様の動作になるんでしょうか。

やっぱそうじゃないんでしょうか？　limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
（offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。

問題は、そのくるくる回す部分を「私がプログラミングする必要があるかどうか」じゃないでしょうか？

>  ＃Listのノードを先へたどるときに、｢未取得｣と「最後」の2種類のステータスがあるとか。
>  それとも全結果が確定してからList等をクライアントで受け取ることになるのでしょうか。

さあ？　ＯＯＤＢってのは誰が（どこで）やるのが一番ベストなんでしょう？

私としては、「私がコーディングする必要があるか否か」が重要であって、ＤＢＭＳが担当しようと、
ＤＢＭＳ以外が担当しようと、速度的に同じであればＤＢＭＳ内に標準化されていようがＤＢＭＳ外で
標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。

次の問題としては、ベンダー（というか製品）によってアクセス方法に違いがあるってことですが（RDBでいうところのSQL)、
これは理想論なんでしょうかね？　SQLが無い時代を考えたら進歩する可能性もあるのかもしれませんね。

＃オブジェクト指向なら、継承で独自拡張路線？

http://mevius.5ch.net/test/read.cgi/db/1057157392/87

88: NAME IS NULL [age] 04/07/21 13:54 ID:???

>>87
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。

確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。

この手の話だとOODBの特徴について議論しているうちに「要は適材適所」とい
う落ち着かせ所が出て来てしまうんですが、それは初めから当然のこととして
わかっているわけで。

しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
しれませんが。

営業活動の結果としてこんなところで使われているという話よりも、OODBの性
質上こんな使い方が向いているという点が分かりやすく出てこないですかねえ。

最もそれをいうとRDBも別にユーザから「リレーショナルモデルが使いたい」
とか「SQLでコーディングしたい」なんて要望があるわけじゃなくて、クライ
アントサーバがブームになったときにRDBMSぐらいしかそれを実現する手段が
無かったから使われたんだと思いますけど。

> 個人的には、RDBに限界を感じてますね。RDBはデータ構造が２次元ですが、階層的に持ちたいって思う事が
> 多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
> 変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。

そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
葉のアヤであって、別に2次元でモデル化しようというわけでもないし。

OODBでは「プログラム中の構造がそのまま格納できる」というのを売りにして
いますが、じゃあRDBでは「プログラム中で頻繁に使う2次元配列を簡単に格納
できる」のが売りかというと全然そんなこと無いし。

変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
ピンと来ません。

そりゃあコンパイルしてテスト通して納品しておしまいなら良いんですが、そ
れまでシステムが稼動して蓄積してきたデータ資産や他アプリケーションがあ
るわけで。

異なるオブジェクトモデル間をコンバートやラッピングする手法／ツールが出
てきてるんでしょうか?

しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。

http://mevius.5ch.net/test/read.cgi/db/1057157392/88

93: NAME IS NULL [age] 04/07/23 12:46 ID:???

>>90
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
> や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。

あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。

少なくともそうしたものを暗黙的に想定します。

> 別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。

これも不思議です。プログラムの構造そのままに格納したいのであれば、オブ
ジェクト指向云々とは全く関係なくその要望はあるように思います。例えば
ObjectStoreがプログラム実行時の仮想メモリをそのまま保存できるからすご
いんだ、と宣伝していましたが、仮想メモリはオブジェクト指向によってもた
らされたものではないですし。

> 速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
> 市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。

「OODBは速い」というのは昔々のoo1やOO7ベンチマークでjoinとpointer chasingを
比較したところから始まっていると思いますが、そのときの比較はRDBもOODB
も研究用プロトタイプで行っていたように思います。実際の性能なんてモデル
なんかよりも実装テクニックの方がはるかに影響が大きいと思うんですけど。

結果やその伝聞を真に受けて「RDBをOODBに入れ替えれば速度が1000倍になる」
と早合点して、無茶なシステムの企画を立てた人がもしかしたらいたのかも。

＃そういえばObjectStoreに不利な結果が出たから弁護士を使って論文から削
＃除させたこともあったような。

http://mevius.5ch.net/test/read.cgi/db/1057157392/93

上下前次 1-新書関写板覧索設栞歴

あと 215 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.015s