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

1 :名無しさん@お腹いっぱい。:03/07/02 23:49 ID:L/c0q833.net
javaの盛り上がりでOODBに移行していくと思いきや
O-Rマッピングかよ!
語りやがれ!

2 :名無しさん@お腹いっぱい。:03/07/03 00:04 ID:???

またくそスレ立てやがったか・・・

3 :名無しさん@お腹いっぱい。:03/07/03 00:15 ID:UvAyQVVL

4 :千葉糞DB連盟:03/07/03 00:43 ID:???

ほっとけほっとけ。

どうせこんなスレすぐにdat落ちするんだからよぉ

5 :名無しさん@お腹いっぱい。:03/07/03 01:09 ID:???

OODBとRDBの違いを教えて。
OODBは継承ベースデータベースって事?

6 :名無しさん@お腹いっぱい。:03/07/03 01:21 ID:???

ORDBっつーのもあった気がする

7 :名無しさん@お腹いっぱい。:03/07/05 15:41 ID:???

XML-DBじゃダメかい?

8 :名無しさん@お腹いっぱい。:03/07/06 00:27 ID:???

>>6
PostgreSQLのことだっけ?
テーブルの継承とかできるっていう。

使うか? あれ。

9 :名無しさん@お腹いっぱい。:03/07/06 02:11 ID:???

>>7
面白いけど重すぎ。

10 :7:03/07/07 00:50 ID:???

>>9
重いのか。しかし盛り上がらないなぁ。
まぁOODBってDBを頻繁に扱う人間にとってはどうでもいい存在なんだろうな。
俺はDBドシロウトだからむしろ興味深いんだが。

11 :名無しさん@お腹いっぱい。:03/07/11 21:57 ID:???

Java用のOODBで実績あるのって何?

12 :名無しさん@お腹いっぱい。:03/07/12 00:34 ID:E4gmilr7

オブジェクト指向データベースの事が理解できません。
なんか便利そうなのは分るけどリレーショナルとどこが違うのか
やさしく叱りながら教えてください。

13 :名無しさん@お腹いっぱい。:03/07/14 16:26 ID:Cb391GNe

「オブジェクト指向データベース」定義が解説書によって
異なっていたりするのには混乱した。
OMGのDB版、ODMGが公開しているのが正しい定義ということでよろしい?

14 :名無しさん@お腹いっぱい。:03/07/15 10:24 ID:???

OracleはOODB?

15 :名無しさん@お腹いっぱい。:03/07/16 00:07 ID:pi7rfdPX

Object Store PSE: ttp://www.tis.co.jp/product/ostore/OSTORE/PSE/FRAMESET.htm
Objectivity/DB: ttp://www.ogis-ri.co.jp/otc/products/objectivity/index.html

16 :名無しさん@お腹いっぱい。:03/07/16 15:00 ID:l8xjyibq

うんこーーーーーーーーーーーーー

17 :名無しさん@お腹いっぱい。:03/07/19 00:14 ID:OyiHRbbd

OODBっていうくらいだから、継承ができんのかな?
参照項目をSQLで結んでやんなくてもいいとか?
開発するんだったら楽チンそうですね

18 :あぼーん:あぼーん

あぼーん

19 :名無しさん@お腹いっぱい。:03/07/20 04:40 ID:Fs8ijVwW

テストデータ作成とか、データをCSVで作ったり、データのローディングしたり。
こんな作業はどうするの?

22 :名無しさん@お腹いっぱい。:03/07/24 06:35 ID:???

遊べるフリーのOODBってないよね?
Zopeが感覚的にかなりOODBに近いと感じたんだけど…

21 :名無しさん@お腹いっぱい。:03/07/21 01:32 ID:???

>>20
ObjectStoreについて調べてみれ

20 :名無しさん@お腹いっぱい。:03/07/20 12:08 ID:???

オブジェクトリレーショナルデータベースと

オブジェクト指向型データベースの違いがわからん。

PostgreSQLはリレーショナルのほうに相当するらしいが。

23 :あぼーん:あぼーん

あぼーん

24 :名無しさん@お腹いっぱい。:03/07/27 01:26 ID:ww4gq4YT

オラクルのオブジェクトリレーショナルは、是非使いたいが。
実務での話になると、強引に進めれる相当な強権を持ってるか、
コケてもOKなしょぼしょぼの自社内システムでしか作れないな。

まず、あれを使えば、開発側からブーイングが出るやろうし、
なにより、
「速度は、保証できんねんな?」
と迫られれば、
「普通で行きます。」
と答えるしかない。
「速度は、保証できるんか?」
やって。普通のDBでも投げるSQLで全然速度は変わるっちゅうねん。畜生。
お前らが、印刷したらB4一枚埋まる様な巨大なSQLを投げるから遅いねん。
誰がメンテすんねん。あんなSQL。

だれか、オラクルのオブジェクトリレーショナルで、DBを構築してしまった
人いる?実務で。

25 :名無しさん@お腹いっぱい。:03/07/27 20:41 ID:???

>>5
OOのシステムでRDBを使うと、オブジェクトの状態を表形式に変換して保存しなければなりませんが、
OODBはオブジェクトの状態をそのまま永続化できます、属性とか関連とか。

らしい。

http://www.ogis-ri.co.jp/otc/hiroba/technical/objy/step1.html

26 :名無しさん@お腹いっぱい。:03/07/27 21:09 ID:U28p0G+i

不勉強ですまんが、OODBって、シリアライズして普通のファイルに保存するのに較べて何か利点あるの?
永続化したいオブジェクトをHashMapに入れて一気に直列化すればトランザクションの
まねごともできるから、あんまOODBの必要性を感じない今日この頃。

27 :あぼーん:あぼーん

あぼーん

28 :名無しさん@お腹いっぱい。:03/07/27 21:41 ID:???

>>26
ロックとかアクセス権限とか、かなぁ。

29 :名無しさん@お腹いっぱい。:03/07/27 23:14 ID:KTLjujEW

>>26
DBのなかでもオブジェクトには生きていてほしいんです。

だからトリガやアサーションなんかも。

30 :あぼーん:あぼーん

あぼーん

31 :名無しさん@お腹いっぱい。:03/07/28 04:10 ID:???

>30
肛門だったらアナルじゃなくてアヌスだろ、馬鹿が。
アナルは「肛門の」という形容詞だ。
他にもオーラル(口の)マニュアル(手の)と色々あるがな。

と宣伝コピペにマジレスしてみる。
しかもこんな時間に。

32 :名無しさん@お腹いっぱい。:03/07/28 05:06 ID:???

徹夜中。
OODBって言語に依存せざるをえないと思うんだけど、言語非依存の実装やってる奴ってないのかな。

たとえばC++なんかはリフレクションもないわけで、OODBに格納するのはやりづらそうなんだが…
メモリ内容をそのまま固めたんじゃ、他の言語からアクセスできないしね。

そこらへん、どうにか解決してる実装があったら教えて欲しいです。

33 :名無しさん@お腹いっぱい。:03/07/28 12:11 ID:Whoi2Qyb

>>26

例えば,ノードがたっくさんある木構造のオブジェクトで,
どっかのノードを一つだけ update したばあい,

* 直列化 : 木構造全体を保存する
* OODB : 修正したノードだけ保存する

と,なるのではないかな.

34 :あぼーん:あぼーん

あぼーん

35 :あぼーん:あぼーん

あぼーん

36 :あぼーん:あぼーん

あぼーん

37 :名無しさん@お腹いっぱい。:03/07/30 02:17 ID:lWu+Xd4c

>>33
それって、
class Person { String FirstName; String LastName; }
っていうクラスのオブジェクトでLastNameのみを更新した場合に、
Personのオブジェクト自体は直列化しなおさないってこと?

38 :あぼーん:あぼーん

あぼーん

39 :名無しさん@お腹いっぱい。:03/07/30 12:20 ID:???

>>37
まあ、イメージとしてはそんなもの。
実際は仮想メモリのページ単位だったりするんだけど。

44 :あぼーん:あぼーん

あぼーん

48 :名無しさん@お腹いっぱい。:03/09/04 07:55 ID:qJ02ntW8

SybaseにOODBの製品なんてあったっけ?

51 :名無しさん@お腹いっぱい。:03/09/19 14:39 ID:9kTuVrlL

いたすかあげ

54 :NAME IS NULL:03/11/05 22:30 ID:QWIrGJf0

c++対応のフリーのOODBMSない?

58 :名無しさん@お腹いっぱい。:03/12/09 11:26 ID:9pNPj1xu

>>56
> またOODBでは開発言語(JavaとかC++とか)でデータベースを操作できるので、SQLを覚えなくてもよい。

OODBでもQuery Languageは必要では?
上は更新系のことだと思うけど。

70 :NAME IS NULL:03/12/18 22:52 ID:???

>>69
Ozone

お勧めかどうか知らないが、一応フリーでOODB。

84 :NAME IS NULL: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を使いまくるこ
とは変わらなくなっちゃったし。

143 :NAME IS NULL:04/08/10 17:04 ID:???

>>142
> 「時代に逆行」というか、キャッシュアーキテクチャを取っているための
> トレードオフと考えたほうがいいでしょう。

「キャッシュアーキテクチャ」を主眼にとっているのなら、やはり「クライア
ント−サーバ」とはレイヤが異なっていると感じます。
どちらかというと「共有メモリ」とか「ソケット」に近いんじゃないでしょうか。

「システムをクライアントサーバ方式で構築する」とは言っても「システムを
共有メモリ方式で構築する」というのは違和感を覚えます。

「共有メモリ」を無理やりシステム方式のレイヤへ持ってくるようなおかしさ
を上のキャッシュアーキテクチャでは感じます。

他のOODBではサーバへOIDをリクエストして、目的のオブジェクトをクライア
ントが取得すると思うので、こうしたことは当てはまらないと思いますが。

> OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
> 変わらないはずです。逆に変わるとすると設計に問題があるでしょう。

その通り、変わりません。設計に問題が出やすいかどうかです。以下は私の感
じていることなのでプログラミング畑の人のほうが距離感がわくでしょうから
コメントが欲しいところ。

RDB系の場合、DB設計担当者が永続化に特化して作業します。また、機構上ア
プリの構造が入り込むことはありえません。
(だからアプリ設計者からSQLへの不満が出てくるわけで)

OODBの場合はどうなるんでしょうか?

アプリ設計者がDB設計者も兼ねるのなら、OO設計で永続性に注意してクラスを
区分するような設計が望めるのでしょうか。(これは上の方に書いたレコード
設計とジャンプテーブル設計に関する文化の懸念)
#ObjectStoreの場合、どういう永続化設計をしなきゃいけないのかは知らないです。

永続化クラスを専門に設計する担当者がいるのなら、そのクラスを使うアプリ
設計者は設計の自由度が無いと感じたり、「作ったクラスがそのまま永続化」
というOODBが目指した利点を享受できないことにならないでしょうか。

その永続化クラス設計者はクライアントのアプリケーション特性、マシン環境
と共にサーバのマシン環境やネットワークにまで考慮が必要となり、求められ
る技術スキルがRDBと比べて驚異的に高くなってしまい、敷居が高くならない
でしょうか。

> XPで有名なKent Beckは「日々のスキーマ更新」を
> プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
> はスキーマ更新が簡単なのですかね?

GemStoneはSmalltalkベースですからC++ベースのものよりはやりやすいかもし
れませんね。(←単なる印象論)

XP(というかオブジェクト指向も含むプログラミング関連トピック全般)は「す
でに保存したデータ」に関しては何も考慮していないんじゃないでしょうか。
で、現実はそうもいかないからDBにアクセスしなきゃいけなくなって「面倒く
さいな」と不満が出る。

172 :NAME IS NULL:04/08/26 01:13 ID:???

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

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

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

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

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

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

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

277 :NAME IS NULL:2008/06/25(水) 19:43:52 ID:TGcEK7R9

>>276

そうそう、サンプルが少ないから未だにDAOからオブジェクト追加出来ない俺…orz

組み込みなんだ?

自社製品になら納得。

301 :NAME IS NULL:2017/04/15(土) 06:27:52.60 ID:PAxoNq0R

realmはここでいうオブジェクトデータベースになる?

305件をまとめました。
最新情報はこちら