OODB - オブジェクト指向データベース (310ﾚｽ)
上下前次1-新
77: [age] 04/06/08 10:14 ID:??? AAS
半年振りにレスがきて懐かしい。
>>76
> 格納とか取り出すって考え方がそもそも無い気がする。
> インスタンス作ったら、それがそのまま永続化されてたような。
ということは、アプリケーションは将来にわたって参照する可能性のあるオブ
ジェクトを、あらかじめ全てハンドリングしているということ？
78(1): 76 04/06/08 23:47 ID:??? AAS
ごめん、俺バカなんで、もうちょっとバカにも分かるように書いてちょうだい(´･ω･`)
79(3): [age] 04/06/09 10:47 ID:??? AAS
>>78
すまん、先走りすぎた。
インスタンスを作るとそのまま自動的に永続化されて、後からそのインスタン
スを参照すると自動的に取り出される、と考えて良いんだよね？
立ち上がったアプリケーションがあるインスタンスを参照するためには既にポ
インタを持っているか、ポインタをたどればそのインスタンスへ行き着く、と
想像しているんだけど。
そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
ているインスタンスはどうやって取り出すんだろうか？
そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
省7
80: 04/06/09 22:37 ID:??? AAS
>>79
ZODBって、Python OrientedなDBっぽいんだけれど、
rootって一番基本になるオブジェクトがあって、
そこから、rootオブジェクトに対して、連想配列みたいな感じで
DBに入ってるインスタンスにアクセス出来るっぽい。
データを格納して検索してっていうよりも、プログラムそのまま入ってるっていうか、
シリアライズ不要で、生のオブジェクトをそのまま格納する場所って感じ？
なんか、自分でも良くわかんなくなってきた。
Cacheなんかは、SQLも使えるらしいし、全然違う物なのかな？
ZODBを使用しているZopeを使用しているだけのユーザなんで、
省1
81: 04/06/16 23:11 ID:??? AAS
>>79
OQLってあるみたいだねえ。詳細知らんけど。
http://www.iioss.org/Manual/dbf/dbf9.6.html
82: 04/07/03 10:34 ID:kQUC+wZT(1) AAS
Matrix
http://www.matrixone.com/
は独自のQLを使っている。
が、速度を無視してくれるなら提供されてるJavaのAPIを使えば
その独自QLを使わなくてもすべてJavaでいける。
オブジェクトの取得はインスタンス化する際に主キー＋αを渡すようなイメージ。
83(1): 04/07/15 22:07 ID:9ZnW1i7A(1) AAS
>>79
昔、Objectivityを使ってました。
複雑な構造を持つデータと、頻繁なデータの入れ替わりには
ODBMSしかないのでは。
速度がそもそもORDBMSと違います。
イリジウム衛星の軌道制御にも使われていたらしい。
>そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
>ているインスタンスはどうやって取り出すんだろうか？
DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
ちなみに、名前でオブジェクトを関連づけたりできます。
省7
84(1): [age] 04/07/16 12:04 ID:??? AAS
>>83
> 昔、Objectivityを使ってました。
> 複雑な構造を持つデータと、頻繁なデータの入れ替わりには
> ODBMSしかないのでは。
> 速度がそもそもORDBMSと違います。
ここは、キーボードから打ち込む文法の問題なのか、それが実行されるときの
アーキテクチャの問題なのかが一緒になっている気がするので分けて考えたい
です。
> イリジウム衛星の軌道制御にも使われていたらしい。
イリジウム自体が尻つぼみだったけど、当時盛んに宣伝してましたね。総容量
省31
85(2): 04/07/16 12:18 ID:??? AAS
>>84
83じゃないけど
> そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
> てくれるんじゃないでしょうか。
> 自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
> 比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。
そういうのがパッケージとして用意されていれば問題ない気がする。
そのパッケージがＤＢベンダーからそろって提供されれば今のＲＤＢＭＳのように
なるだろうし、Javaで標準ができてCORE APIかJ2EEにでもなろうものなら、どの
ＯＤＢであろうとベンダーによって文法が変わったりとかせずに、それ以前にデー
省8
86(1): [age] 04/07/20 15:03 ID:??? AAS
>>85
少し話題が他の方向へ行きましたが。
> そういうのがパッケージとして用意されていれば問題ない気がする。
<snip>
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。
そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
るメリットはどの辺にありそうでしょうか。
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
省17
87(2): 85 04/07/20 22:40 ID:??? AAS
>>86
あんまり詳しくないんですが、
> そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
> クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
> るメリットはどの辺にありそうでしょうか。
重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
省29
88(3): [age] 04/07/21 13:54 ID:??? AAS
>>87
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。
省29
89(1): [age] 04/07/21 13:56 ID:??? AAS
>>87
長くなったので分割。
> ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。
ごりごりプログラムしているわけではないので詳しくは分かりませんが、なん
となく理解できました。
> やっぱそうじゃないんでしょうか？ limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
> （offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。
limit等は最終的に返す個数の指定ですが、RDBなどでは例えば検索結果が100
万件あったら確定した結果が順次クライアントへ送られる、という意味で
「Streaming」と書きました。クライアントが1件目の結果を処理しているとき
省11
90(3): 04/07/21 22:19 ID:??? AAS
>>88
> 確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
> なのかのイメージがつかめません。
> 世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
> 便利」というのが分かりづらいです。
んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
省6
91(1): 04/07/21 22:32 ID:??? AAS
>>88
ああ、長くなったので分割したら、後半がきえてしまった。orz
> そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
> 葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
状態になったり、今まで必須だった項目がまったく不要になったり、、
結構頻繁にあるんですよねえ。
＃うちの会社だけ？
省14
92: 04/07/21 22:38 ID:??? AAS
>>89
> 実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
> ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
> して動作するんだし。
別にJ2EEのようにインターフェイスだけ共通で定義されていて、実装は各ベンダーが
行ってもいいわけです。
私は
「この条件に従ってデータを取ってこい。それが仮に５０万件あろうと、このソー
トキーに基づき４１〜６０件目の２０件だけデータを返せ。」
という命令がしたいだけ。
93(1): [age] 04/07/23 12:46 ID:??? AAS
>>90
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
> や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。
少なくともそうしたものを暗黙的に想定します。
省16
94(1): [age] 04/07/23 12:55 ID:??? AAS
>>91
> RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
2次元の表ではなくて、正式にはリレーションだし、現実的には単なるレコー
ド設計でしょう。レコードを沢山集めて2次元に表示できるということなら、
オブジェクトを集めたって同じことが言えると思います。
複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
queryが付いたりする。
> システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
> 状態になったり、今まで必須だった項目がまったく不要になったり、、
> 結構頻繁にあるんですよねえ。
省16
95(1): 04/07/23 21:28 ID:??? AAS
>>93
> あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
> 納したい」とは考えないです。
研究者の方ですか？
> だってデータはコンピュータシステムが出来る
> 前から存在していて、システムの外で発生して人間が入力するもので、いざと
> なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
> には可能です。
えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
省10
96(1): 04/07/23 21:43 ID:??? AAS
>>94
> レコードを沢山集めて2次元に表示できるということなら、
> オブジェクトを集めたって同じことが言えると思います。
そうかもしれません。
> 複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
> queryが付いたりする。
だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
> ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
> うなんでしょうか。
省10
上下前次1-新書関写板覧索設栞歴
あと 214 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.010s