O-Rマッピングかよ！
語りやがれ！
Objectivity
ttp://www.objectivity.com/ ObjectStore
ttp://www.odi.com/ GemStone
ttp://www.gemstone.com/ Versant
ttp://www.versant.com/ どうせこんなｽﾚすぐにdat落ちするんだからよぉ
OODBは継承ベースデータベースって事？
PostgreSQLのことだっけ?
テーブルの継承とかできるっていう。
使うか? あれ。
面白いけど重すぎ。
重いのか。しかし盛り上がらないなぁ。
まぁOODBってDBを頻繁に扱う人間にとってはどうでもいい存在なんだろうな。
俺はDBドシロウトだからむしろ興味深いんだが。
なんか便利そうなのは分るけどリレーショナルとどこが違うのか
やさしく叱りながら教えてください。
異なっていたりするのには混乱した。
OMGのDB版、ODMGが公開しているのが正しい定義ということでよろしい？
ttp://www.tis.co.jp/product/ostore/OSTORE/PSE/FRAMESET.htm Objectivity/DB:
ttp://www.ogis-ri.co.jp/otc/products/objectivity/index.html 参照項目をSQLで結んでやんなくてもいいとか？
開発するんだったら楽チンそうですね
こんな作業はどうするの？
オブジェクト指向型データベースの違いがわからん。
PostgreSQLはリレーショナルのほうに相当するらしいが。
ObjectStoreについて調べてみれ
Zopeが感覚的にかなりOODBに近いと感じたんだけど...
実務での話になると、強引に進めれる相当な強権を持ってるか、
コケてもＯＫなしょぼしょぼの自社内システムでしか作れないな。
まず、あれを使えば、開発側からブーイングが出るやろうし、
なにより、
「速度は、保証できんねんな？」
と迫られれば、
「普通で行きます。」
と答えるしかない。
「速度は、保証できるんか？」
やって。普通のＤＢでも投げるＳＱＬで全然速度は変わるっちゅうねん。畜生。
お前らが、印刷したらＢ４一枚埋まる様な巨大なＳＱＬを投げるから遅いねん。
誰がメンテすんねん。あんなＳＱＬ。
だれか、オラクルのオブジェクトリレーショナルで、ＤＢを構築してしまった
人いる？実務で。
OOのシステムでRDBを使うと、オブジェクトの状態を表形式に変換して保存しなければなりませんが、
OODBはオブジェクトの状態をそのまま永続化できます、属性とか関連とか。
らしい。
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/objy/step1.html 永続化したいオブジェクトをHashMapに入れて一気に直列化すればトランザクションの
まねごともできるから、あんまOODBの必要性を感じない今日この頃。
ロックとかアクセス権限とか、かなぁ。
ＤＢのなかでもオブジェクトには生きていてほしいんです。
だからトリガやアサーションなんかも。
肛門だったらアナルじゃなくてアヌスだろ、馬鹿が。
アナルは「肛門の」という形容詞だ。
他にもオーラル(口の)マニュアル(手の)と色々あるがな。
と宣伝コピペにマジレスしてみる。
しかもこんな時間に。
OODBって言語に依存せざるをえないと思うんだけど、言語非依存の実装やってる奴ってないのかな。
たとえばC++なんかはリフレクションもないわけで、OODBに格納するのはやりづらそうなんだが...
メモリ内容をそのまま固めたんじゃ、他の言語からアクセスできないしね。
そこらへん、どうにか解決してる実装があったら教えて欲しいです。
例えば，ノードがたっくさんある木構造のオブジェクトで，
どっかのノードを一つだけ update したばあい，
* 直列化 ： 木構造全体を保存する
* OODB ： 修正したノードだけ保存する
と，なるのではないかな．
それって、
class Person { String FirstName; String LastName; }
っていうクラスのオブジェクトでLastNameのみを更新した場合に、
Personのオブジェクト自体は直列化しなおさないってこと？
まあ、イメージとしてはそんなもの。
実際は仮想メモリのページ単位だったりするんだけど。
それはOODBじゃなくてObjectStore。
他のアーキテクチャで代表的な実装ってどんなのがある?
物理的な実装までは知らないけど、Page ServerなのがObjectStore。Versant
なんかがObject Server。なのでVersantは排他制御がオブジェクト単位で可能。
仮想メモリを利用してPage ServerにするのはObjectStoreがパンフで「独自特
許」と誇らしげにしてたから、他のベンダはやってたのかな？
実装の言語依存度合いは
ObjectStore >> Versnat, Objectivity, GEMSTONE >> O2, ITASCA
だった印象が残ってる。（資料比較レベルで）
10年前の知識と記憶だからちょっと不確かかも。Jasmineとかになると全然フォ
ローできない。
ttp://www.service-architecture.com/index.html ttp://galaxy.uci.agh.edu.pl/~vahe/products.htm このあたりからたどって参考にしてみて。
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
あなたを待ってたので
Rerational DBは、関係演算に基づいてデータを管理する。
データは複数のテーブルに分けて格納し、テーブル間は外部キーを用いて関係づける。
DBの操作はSQLで行う。そのため、プログラムの開発言語に依存しないという利点はあるが
逆にいえば開発言語とは異なる言語を覚えなけらばならない。
しかもSQLが手順を記述するような言語ではなく、宣言的な言語であるため、覚えるのは結構面倒。
OODBは、『オブジェクトを保存する』という考えを基本にしたDB。
つまりあなたがnewしたインスタンスは何の苦労もなくそのままDBに格納できる。
これがRDBならクラス定義と対応づけたテーブルを用意し、オブジェクトを保存するためのSQLを
いちいち用意しなくてはならない。
またOODBでは開発言語（JavaとかC++とか）でデータベースを操作できるので、SQLを覚えなくてもよい。
それからRDBもOODBも、トランザクション管理とか権限の管理はできる。
これはDBMS(DB Management System)としての機能だから、RDBだろうがOODBだろうが関係ない。
Javaでオブジェクトを保存するだけなら、シリアライズしてファイルに書き込む方法でもいいけど、
こういった機能を使うにはOODBを使うのがよい。
使っている人います？
ttp://www.ozone-db.org/frames/home/what.html > またOODBでは開発言語（JavaとかC++とか）でデータベースを操作できるので、SQLを覚えなくてもよい。
OODBでもQuery Languageは必要では？
上は更新系のことだと思うけど。
必要ないよ。
サンプル教えて。使ったことないせいか、「query(条件文の羅列)」みたいな
のは必要だと思い込んでた。
サンプルってか、new foo(bar,bu,bi)でインスタンスの生成
foo.updateで更新、foo.siraizeで格納。
こんなイメージで扱えるのがOODB
databaseobject.select(Query)てなイメージが有るの？
一回格納したインスタンスはどうやって取り出すの？
OODB使え。嘘だと思ってるのか、馬鹿か、どっちかだな（ｗ
わざわざ2chの書き込みのために使ってみる気はしません。
ちなみに私が「嘘だと思っている」のか「馬鹿」かどっちだと思いますか？
66は64へのレスです。
61であがっているのは更新系だけなので、参照系はどうなのかなと。
SQL99で定義されてない構文だからQLじゃない、という意味じゃないですよねぇ。
大昔VERSANT(1.1の頃)を触ったときにはQLらしきものがあったんですが、今はもう無くなったんですかね。
でもどうやって無くなったんだろう？
＃こんな話をするのは１０年前のNifty以来だ（笑）
61,62,64の人がOODBを熱く語ってくれないかな。
Ozone
お勧めかどうか知らないが、一応フリーでOODB。
何種類かあるのね。フリーなOODBも。
誰も使ってないのかな？
ttp://www.linas.org/linux/db-non-sql.html Zopeしか知らないけれど、
格納とか取り出すって考え方がそもそも無い気がする。
インスタンス作ったら、それがそのまま永続化されてたような。
> 格納とか取り出すって考え方がそもそも無い気がする。
> インスタンス作ったら、それがそのまま永続化されてたような。
ということは、アプリケーションは将来にわたって参照する可能性のあるオブ
ジェクトを、あらかじめ全てハンドリングしているということ？
すまん、先走りすぎた。
インスタンスを作るとそのまま自動的に永続化されて、後からそのインスタン
スを参照すると自動的に取り出される、と考えて良いんだよね？
立ち上がったアプリケーションがあるインスタンスを参照するためには既にポ
インタを持っているか、ポインタをたどればそのインスタンスへ行き着く、と
想像しているんだけど。
そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
ているインスタンスはどうやって取り出すんだろうか？
そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
装もあるし、MDA絡みでも似たような宣言的構文ができて、｢サーバにリクエス
トを出す→目的のものを受け取る｣ということを昔からやってきてるはず。
ところが上の方のレスだと「OODBならそんなの必要ないじゃん」ということら
しいので、もっと詳しく聞きたかったんだけど。
Query Languageが無いと「suspendとdumpが賢くなって、セーブ機能を簡単に
実装できます｣というような、stand aloneアプリケーション組み込み用のDBに
しかならないような気がする。
ZODBって、Python OrientedなDBっぽいんだけれど、
rootって一番基本になるオブジェクトがあって、
そこから、rootオブジェクトに対して、連想配列みたいな感じで
DBに入ってるインスタンスにアクセス出来るっぽい。
データを格納して検索してっていうよりも、プログラムそのまま入ってるっていうか、
シリアライズ不要で、生のオブジェクトをそのまま格納する場所って感じ？
なんか、自分でも良くわかんなくなってきた。
Cacheなんかは、SQLも使えるらしいし、全然違う物なのかな？
ZODBを使用しているZopeを使用しているだけのユーザなんで、
難しい事分からなくてごめんよ。
OQLってあるみたいだねえ。詳細知らんけど。
ttp://www.iioss.org/Manual/dbf/dbf9.6.html ttp://www.matrixone.com/ は独自のQLを使っている。
が、速度を無視してくれるなら提供されてるJavaのAPIを使えば
その独自QLを使わなくてもすべてJavaでいける。
オブジェクトの取得はインスタンス化する際に主キー＋αを渡すようなイメージ。
昔、Objectivityを使ってました。
複雑な構造を持つデータと、頻繁なデータの入れ替わりには
ODBMSしかないのでは。
速度がそもそもORDBMSと違います。
イリジウム衛星の軌道制御にも使われていたらしい。
>そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
>ているインスタンスはどうやって取り出すんだろうか？
DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
ちなみに、名前でオブジェクトを関連づけたりできます。
> そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
> 装もあるし、MDA絡みでも似たような宣言的構文ができて、｢サーバにリクエス
> トを出す→目的のものを受け取る｣ということを昔からやってきてるはず。
そもそも、DBのクラスライブラリーに強力なコレクション・クラスがあるので
その検索メソッドを呼び出すなり、そのクラスを使用して強力なコレクション・クラスを作れば
SQLみたいに、文を生成する必要はないです。
ただ、他の言語バージョンに同様のクラス・ライブラリーが移植されていなければ諦めるしかないです。
> 昔、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を使いまくるこ
とは変わらなくなっちゃったし。
83じゃないけど
> そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
> てくれるんじゃないでしょうか。
> 自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
> 比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。
そういうのがパッケージとして用意されていれば問題ない気がする。
そのパッケージがＤＢベンダーからそろって提供されれば今のＲＤＢＭＳのように
なるだろうし、Javaで標準ができてCORE APIかJ2EEにでもなろうものなら、どの
ＯＤＢであろうとベンダーによって文法が変わったりとかせずに、それ以前にデー
タへアクセスするソースとかは一切変更しなくていいわけだし。
どっちの方向に行くのか俺には分かんないけどね。
> プログラムから呼び出す方法を考えるときに、未知の不定個のデータを扱う良
> い方法が無いこともあって、SQLをそのまま埋め込んでループでまわすなんて
> いう方法に落ち着いちゃったんでしょう。
ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
してくれるから、そのままオブジェクト指向として使える。
ループで回すって言うなら、RDBに関係なくCOBOLでもそうじゃないのかな。
少し話題が他の方向へ行きましたが。
> そういうのがパッケージとして用意されていれば問題ない気がする。
<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)の不満点でした。
＃なんか質問ばっかだな。
あんまり詳しくないんですが、
> そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
> クエンドにある格納／トランザクション管理システムを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が無い時代を考えたら進歩する可能性もあるのかもしれませんね。
＃オブジェクト指向なら、継承で独自拡張路線？
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。
この手の話だとOODBの特徴について議論しているうちに「要は適材適所」とい
う落ち着かせ所が出て来てしまうんですが、それは初めから当然のこととして
わかっているわけで。
しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
しれませんが。
営業活動の結果としてこんなところで使われているという話よりも、OODBの性
質上こんな使い方が向いているという点が分かりやすく出てこないですかねえ。
最もそれをいうとRDBも別にユーザから「リレーショナルモデルが使いたい」
とか「SQLでコーディングしたい」なんて要望があるわけじゃなくて、クライ
アントサーバがブームになったときにRDBMSぐらいしかそれを実現する手段が
無かったから使われたんだと思いますけど。
> 個人的には、RDBに限界を感じてますね。RDBはデータ構造が２次元ですが、階層的に持ちたいって思う事が
> 多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
> 変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。
そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
OODBでは「プログラム中の構造がそのまま格納できる」というのを売りにして
いますが、じゃあRDBでは「プログラム中で頻繁に使う2次元配列を簡単に格納
できる」のが売りかというと全然そんなこと無いし。
変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
ピンと来ません。
そりゃあコンパイルしてテスト通して納品しておしまいなら良いんですが、そ
れまでシステムが稼動して蓄積してきたデータ資産や他アプリケーションがあ
るわけで。
異なるオブジェクトモデル間をコンバートやラッピングする手法／ツールが出
てきてるんでしょうか?
しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。
長くなったので分割。
> ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。
ごりごりプログラムしているわけではないので詳しくは分かりませんが、なん
となく理解できました。
> やっぱそうじゃないんでしょうか？ limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
> （offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。
limit等は最終的に返す個数の指定ですが、RDBなどでは例えば検索結果が100
万件あったら確定した結果が順次クライアントへ送られる、という意味で
「Streaming」と書きました。クライアントが1件目の結果を処理しているとき
はサーバは50万件目を探しているかもしれない。
> 私としては、「私がコーディングする必要があるか否か」が重要であって、ＤＢＭＳが担当しようと、
> ＤＢＭＳ以外が担当しようと、速度的に同じであればＤＢＭＳ内に標準化されていようがＤＢＭＳ外で
> 標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。
私としては、システムというのは動かして使われるためのものなので、コーディ
ングの便宜よりもどういうアーキテクチャで動くのかとか、稼動させたときの
運用制限はどうなるのかという点の方を重視したいです。
実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
して動作するんだし。
＃暑すぎて仕事がはかどらないくせに長文w。 2chに文字数制限があるのをはじめて知った。
> 確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
> なのかのイメージがつかめません。
> 世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
> 便利」というのが分かりづらいです。
んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
> いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
> しれませんが。
速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。
今はそれに変わって既存のＲＤＢがオブジェクトもいけますよっていうＯＲＤＢがでてきてますね。Oracleしかり、MSSQLしかり。
まあ、これからのもんでしょうけど。
ああ、長くなったので分割したら、後半がきえてしまった。orz
> そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
> 葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
状態になったり、今まで必須だった項目がまったく不要になったり、、
結構頻繁にあるんですよねえ。
＃うちの会社だけ？
> 変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
> ピンと来ません。
んー、オブジェクト指向だからってことはないのかもしれませんねえ。
> 異なるオブジェクトモデル間をコンバートやラッピングする手法／ツールが出
> てきてるんでしょうか?
O/Rマッピングツールでしたら、私のお薦めはこれ。
ttp://www.ibatis.com/common/sqlmaps.html > しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
> たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。
仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は２つあります。
・一から作り直す。
・今のを修正して、無理にでも動かす。（もち問題先送り）
で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、
> 実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
> ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
> して動作するんだし。
別にJ2EEのようにインターフェイスだけ共通で定義されていて、実装は各ベンダーが
行ってもいいわけです。
私は
「この条件に従ってデータを取ってこい。それが仮に５０万件あろうと、このソー
トキーに基づき４１〜６０件目の２０件だけデータを返せ。」
という命令がしたいだけ。
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
> や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。
少なくともそうしたものを暗黙的に想定します。
> 別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
これも不思議です。プログラムの構造そのままに格納したいのであれば、オブ
ジェクト指向云々とは全く関係なくその要望はあるように思います。例えば
ObjectStoreがプログラム実行時の仮想メモリをそのまま保存できるからすご
いんだ、と宣伝していましたが、仮想メモリはオブジェクト指向によってもた
らされたものではないですし。
> 速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
> 市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。
「OODBは速い」というのは昔々のoo1やOO7ベンチマークでjoinとpointer chasingを
比較したところから始まっていると思いますが、そのときの比較はRDBもOODB
も研究用プロトタイプで行っていたように思います。実際の性能なんてモデル
なんかよりも実装テクニックの方がはるかに影響が大きいと思うんですけど。
結果やその伝聞を真に受けて「RDBをOODBに入れ替えれば速度が1000倍になる」
と早合点して、無茶なシステムの企画を立てた人がもしかしたらいたのかも。
＃そういえばObjectStoreに不利な結果が出たから弁護士を使って論文から削
＃除させたこともあったような。
> RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
2次元の表ではなくて、正式にはリレーションだし、現実的には単なるレコー
ド設計でしょう。レコードを沢山集めて2次元に表示できるということなら、
オブジェクトを集めたって同じことが言えると思います。
複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
queryが付いたりする。
> システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
> 状態になったり、今まで必須だった項目がまったく不要になったり、、
> 結構頻繁にあるんですよねえ。
ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
うなんでしょうか。
> O/Rマッピングツールでしたら、私のお薦めはこれ。
>
ttp://www.ibatis.com/common/sqlmaps.html O/Rマッピングというよりも、既存のオブジェクト指向モデルがあってそれが
すでに稼動している場合、前提条件が覆ってモデルの変更が発生した場合に、
旧モデルから新モデルへの移行は現在保存されているオブジェクトを含めて自
明な方法になるんだろうか、という疑問です。
MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印
象を持っていますが。
> 仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は２つあります。
> ・一から作り直す。
> ・今のを修正して、無理にでも動かす。（もち問題先送り）
> で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
> まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、
この場合の一番の判断要因はもちろんコストでしょう。
> あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
> 納したい」とは考えないです。
研究者の方ですか？
> だってデータはコンピュータシステムが出来る
> 前から存在していて、システムの外で発生して人間が入力するもので、いざと
> なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
> には可能です。
えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
水道は、電気は、車は、
ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
やっぱり私とは考え方というか感覚が違いますね。（だから楽しい！）
> > 別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> これも不思議です。
不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
> レコードを沢山集めて2次元に表示できるということなら、
> オブジェクトを集めたって同じことが言えると思います。
そうかもしれません。
> 複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
> queryが付いたりする。
だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
> ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
> うなんでしょうか。
んー。正確には、適切に設計されていればコードの変更箇所が必要最小限となり、影響される範囲も限定されるわけです。
DBどうのこうのじゃなくて、システム設計の話になりますね。
で、言語で言えば、BASICに比べればCが、Cに比べればJavaが、「適切に設計」されてさえいれば安全性が増しますね。
JavaだからOODBとなったわけで、BASICやCOBOLならシーケンシャルファイルでしょうか。
話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。（ｗ
> MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印
すいません。MDAって何ですか？
> この場合の一番の判断要因はもちろんコストでしょう。
ビジネスの世界ではコストより時間が優先されがちです。
時間＝コストと考えれば、コストですね。
それは幻想のような。
ただのプログラムだって最初の分析が甘ければデータ構造の
見直しが発生しちゃうわけだし。
逆にDOAなど分析手法が確立しているRDBの方が危険性が
少ないようにも思うんだが。
よく分かんない。
まあだいたいトレードオフするものだから、どっからみても完璧なんてあり得ないんだけど、
もし仮にそういう完璧な設計&プログラミングができたとしても、それはその時点でのモデルだよね。
どうせ完璧なんて無いんだから、どうしたら「マシ」なのかを探るべきだと思います。
＃週末で酔っぱらってるので本レスはまた来週。
１）業務を変えない。 無理だな。
２）業務を変えるたびにシステム再構築し直す。 無理だな。
３）業務に変更があった場合、修正箇所を最小限にする。
なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
