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の方が危険性が
少ないようにも思うんだが。
よく分かんない。
まあだいたいトレードオフするものだから、どっからみても完璧なんてあり得ないんだけど、
もし仮にそういう完璧な設計&プログラミングができたとしても、それはその時点でのモデルだよね。
どうせ完璧なんて無いんだから、どうしたら「マシ」なのかを探るべきだと思います。
＃週末で酔っぱらってるので本レスはまた来週。
１）業務を変えない。 無理だな。
２）業務を変えるたびにシステム再構築し直す。 無理だな。
３）業務に変更があった場合、修正箇所を最小限にする。
なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
> ３）業務に変更があった場合、修正箇所を最小限にする。
> なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
で展開してた議論だと思います。
> 過去のプログラムの実行結
> 果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
> で展開してた議論だと思います。
そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
> それはプログラミングの場合は確立されてるけど、
だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのはの（３）に相反しているというのが私の主張です。
#現実的にはRDBしか選択肢がないに等しいんだけどね。
> そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの？」と
いうのが話（やそもそものスレ）の発端でしょ？
> だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのはの（３）に相反しているというのが私の主張です。
それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。
上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
システム開発ってプログラミング関連だけじゃなくて方式設計とか、ネットワー
ク設計とか、ソフトウェア構成とか、いろんな要素が絡んでると思うんだけど。
その時に「DBMS」と呼ばれる構成要素に対して求められる機能を考えたときに、
RDBやOODBはどんな特徴として位置づけられるんだろう、と考えるのが重要だ
と思います。
> 研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。
OODB出始めは本当にアカデミック方面しか資料が無かったし。
でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、
> えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。
カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。
企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。
データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。
> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。
> 経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、
水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
＃極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。
> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?
システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
＃制御系の話はよく分からないんでパス。
> 不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
> ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。
相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
> だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
> オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
オブジェクト指向以外の言語において、プログラミングの便宜のためにレコー
ドの概念が導入されたとは思えません。それは言語の問題の外からの要求に応
えたものだと思います。そしてその関係はオブジェクト指向言語でも変わるべ
きではないと思います。（というか変わる理由が分からない）
> すいません。MDAって何ですか？
Model Driven Architecture(だったかな?)。標準的なオブジェクト指向の道具
立てがそろってきたから、ここらでもう1回CASEの夢を見ようという動きだと、
私は理解をしています。
> ビジネスの世界ではコストより時間が優先されがちです。
> 時間＝コストと考えれば、コストですね。
すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
沢山出て来そう)ということでしょうか。
＃新規の話じゃないですよね。
まあ実際は資産を除却するよりも、追加で出来るならそっちの方が良いという
判断かもしれませんが。
>それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。
DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
それとも相互に影響を与えながら進化していっているのでしょうか？
>>研究者とくるとは、、、
それとも学生か学者かと。
>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理
別に揚げ足じゃないですが、判を押した請求書をつくらないところもありますよ。入金チェックは自動でしているところもあるでしょう。
人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
>便利な手段があるからといって、目的と混同すべきではないです。
便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
手段や目的とはその上で語られる別次元のものです。
>パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
>チして、サーバのディスクからページを転送してくるらしいです。
面白そうですね。OSいらんやんって思いました。
OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。
>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
これはOODBの場合って話ですか？ なぜでしょう？
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
>Model Driven Architecture(だったかな?)。
JavaWorldの５月号に特集を見つけました。今度読んでみます。
>> ビジネスの世界ではコストより時間が優先されがちです。
>> 時間＝コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。
いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし５ヶ月かかる。
・今のをむりやりにでも動くように修正すれば１ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、４ヶ月の時間差（＝コスト）がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に４ヶ月分だけの価値（＝利益）があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
＃ただし私が関わっているシステムはそのどちらでもありません
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
悲惨です。クライアントのキャッシュが肥大してメモリ不足になってしまう
なんてこともあります。
OODBが通常の業務システムに使われないのは、まず技術者が不足している
こと、ベンダのサポートが不安なこと(今はわかりませんが、昔はひどい
もんでした)、それとなにより業務システムにありがちなアドホックなデータ
操作(参照系、更新系含む)が難しいことでしょうか。なにかあるたびに
プログラムを一本作らなければならないのでは、運用が困難です。
ただ、個人的にはOODB(っていうかObjectStore)のキャッシュが使えたらな
、と思うことはよくあります。どんなデータかというと、
・参照は頻繁にされる。また、参照のコストが高い
・更新の頻度は少ないが、更新は即時に反映される必要がある
ようなものです。例えばリソースに対するアクセス制御データとかですね。
（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
（最終的にはCORBA/CCMまで絡ませたい）
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること（ユーザインターフェイスを含む）」なのです。
（以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。）
ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
（MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう）。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ（例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール）が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか？
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
（ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします）
あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
まずは上級エンジニアが触ってみて遊んでみて「いいな、コレ」って思ってもらわなければ、いつまでたっても一部のコアな開発者のマニアックな玩具に留まってしまう気がします。
それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応（←これ重要！2バイト対応されていない製品はユーザに嫌われる）
といったようなものがサクっと出てくるようでないと・・・。
（フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・？）
>（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
お久しぶりです。
＃と言ってもどなたかわかりませんが:-)
>今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
ObjectStore以外のOODB製品はよく知らないのですが、最近Cacheという
製品が気になっています。これが謳い文句どおりの製品ならかなりのもの
ではないかと思うのですが、ちょっと眉に唾をつけてます。暇があれば、
試用版を使ってみたいと思うのですが。
>あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
XMLDBなら、Apache Xindiceはかなり簡単です。私はダウンロードして5分で
とりあえず使えるようになりました。
> DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
> それとも相互に影響を与えながら進化していっているのでしょうか？
もちろん相互に影響を与えているでしょう。
> それとも学生か学者かと。
ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
なんでしょうか?
> 人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
> それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
> 便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
> 手段や目的とはその上で語られる別次元のものです。
アパートを借りる人や都市計画を考える人にとっては水道管はあって当然です。
あって当然ですが、断水してるとか、そもそも水源から繋がってなかったら話になりません。
この例ではITという便利な手段を「構築する人にとって」どう捕らえるべきかという話でしょ?
> 面白そうですね。OSいらんやんって思いました。
> OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
OS組み込みのモジュールならば面白いかもしれませんがOSを置き換えたり、単
独で立ち上げて外部に公開するもんじゃないと思います。
NW・CD-ROM・マウス・キーボードドライバも用意して、コンテキストスイッチ
機能も入れてDBマシンとしてハードウェアごと用意するのは有りかもしれませ
ん。(使いにくそうだけど)
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。
> 外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。
開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
> これはOODBの場合って話ですか？ なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
いくつか考えられますが。
１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。
最初に作った人はハッピーなんでしょうけど。
いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。
２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか？
システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。
３：基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。
思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。
> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。
＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。
> OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
> ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
> につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
> あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
> 悲惨です。
買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
> ・参照は頻繁にされる。また、参照のコストが高い
> ・更新の頻度は少ないが、更新は即時に反映される必要がある
>
> ようなものです。例えばリソースに対するアクセス制御データとかですね。
この利用例のアーキテクチャはどうなっているでしょうか。個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
>１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。
>２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。
これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
高いと思います。
>CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
間で同一データを扱っている際に、更新を即時に反映できることです。
通信系システムで採用されている理由も同じでしょうね。
＃もう一つ共通点としては「データの再利用」や「アドホックな操作」が
＃不要なことも挙げられます
>買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
とプログラムが異常終了します:-P
>この利用例のアーキテクチャはどうなっているでしょうか。
まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
すいません、つながりがよくわかりません。
> できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
> 高いと思います。
個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
ログをXML形式で溜めていくのはありそうですけど。
＃インデキシングやトランザクション・排他制御管理がどうなっているのかはぜ
＃んぜん追っかけてません。
> 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
> 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
> 間で同一データを扱っている際に、更新を即時に反映できることです。
部品管理システムと連動したアプリケーション、というイメージでしょうか。
> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
いいえ、上で書いた知識でほぼすべてです(笑)。
> すいません、つながりがよくわかりません。
アクセスするアプリケーションが固定で、そのアプリケーションを捨て去ると
きにはDBも破棄してしまうとか。「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
業務系・情報系のようにDBを置いておいてあちこちからアクセスされるのを待っ
ているという形態ではないと。
そして、ObjectStoreの「仮想メモリをそのまま云々」というのはそうした
（制御系?組み込み系?）の方が向いてるんじゃないかと想像しています。だか
ら私はObjectStoreは好きになれそうも無いけど、PSEはなんとなく良い印象を
持っています。
＃全部想像ですけど。
> ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
> てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
> ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
> なんでしょうか?
さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
他意はありません。
＃２ｃｈでまじめに議論できるとはめずらしいスレですね。パソ通みたいで懐かしいです。
> ｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
> 能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
> 署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
下す必要があるときだけ、ユーザに伝えればいいと考えます。
> まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
> 象は違わないし、保存する必要性も変わらないと思います。
では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
>> esql/c でもpro*cでもいいですが、プリプロセッサです。
>
>開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
組込型言語とでもいうんですかね。忘れました。
開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
それからコンパイルされ、普通の実行形式のプログラムに変換されます。
>個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
ほうが扱いやすいです。
>部品管理システムと連動したアプリケーション、というイメージでしょうか。
そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
という仕組みに使われているはずです。
>> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>いいえ、上で書いた知識でほぼすべてです(笑)。
各クライアントがメモリ上にキャッシュを持っており、キャッシュ内のオブジェクト
を更新すると、その更新が他のクライアントのキャッシュにも反映される、という
ことでおわかりになるでしょうか。
>「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
たとえば、NTドメインのユーザ/グループ情報と、ファイルに対するアクセス権
の設定をマッチさせて、現在のセッションのユーザが指定されたファイルに対して
指定されたアクションが実行可能かを判別する、といった感じでイメージして
いただけるでしょうか。
>組込型言語とでもいうんですかね。忘れました。
埋め込みSQL(Embeded SQL)ですね。
> さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
確かにプログラマではありません。人の作ったソースの一部を性能チューニン
グのために見たりいじったりしたことはありますが。
システム開発の時にはプログラミング以外にもいろんな技術要因が絡んできま
すよ。
> 研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
業界に何年かいれば、誰でもある程度のシステム観とかポリシーみたいなもの
は出来てくるんじゃないでしょうか。
> 業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
> 自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
> 下す必要があるときだけ、ユーザに伝えればいいと考えます。
この場合例に出していたのは経理の入出金ですからチェックしなきゃいけない
でしょう。月次締めなどを経理の人が必死でやってませんか?そもそもどの請
求書に対応した入金かどうかなんて、十分な情報がある保証は無いですし。
業務上運用手抜きしてノーチェックにしてしまう可能性はありますが。少なく
ともいつでも確認できる状態にしておかないと、システムにバグがあったとき
に対処できないし、会計監査も危ないんじゃないでしょうか。
監視ツールがログを監視して警告を出す、というような場合は通常は無視して
しまって、問題が起こったときに「ここまでは正常だった」ということが分か
れば良いと思います。
> では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。
＃そしてその要求は言語から来るものではありません。
後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
たもんじゃないということは更に上でも書いてます)
> 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
> それからコンパイルされ、普通の実行形式のプログラムに変換されます。
それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
でしょ?
SQLをコードの中に埋め込んだということは、
・その部分が実行されるときはネットワークを介してサーバへリクエストが飛ぶ
・サーバ内で何かが実行される
・その結果が自分のコードの中へ返ってくる
ということがまず考えられて、さらに
・そのサーバへは別のプログラムもリクエストを出している
・今のプロジェクトで開発したプログラムじゃなくて、例えばAccessを使った管理ツールもリクエストを飛ばしている
というようにシステム構成を考えていけば、で挙げたような問題点にぶ
ち当たると思うんですが。
例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
・HTTPサーバをJavaで作った
・WebブラウザもJavaで作った
とここまでは良いとして、
・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
なんて考えないでしょ?
> 複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
> ほうが扱いやすいです。
XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
・referenceは結局ID属性を使いまくりになる。
・そのときの排他制御がどうなるのかいまひとつ分からない。
・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
というあたりが不安視するところです。
> そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
> 即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
> 状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
> という仕組みに使われているはずです。
なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
＃competitorはRDBじゃなくてCORBA。
ObjectStore限定の性質なのか、OODBに共通して見られる特徴なのかは分かり
ませんが、確かにそれは便利そうです。RDBで無理にやろうとしたら定期的に
リクエストを投げてpollingしなきゃいけないところです。
やはりOODBは組み込み向け（機器組み込みじゃなくてアプリケーション組み込
み）に向いている感じがします。
だとするとベンダの営業文句は根本的にはずしてる気がする。今はどうか知り
ませんが、かつては「次世代の企業内基幹システムはオブジェクト指向開発が
広まってOODBだ!」っていう風じゃなかったでしたっけ?
> ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
> とプログラムが異常終了します:-P
これ、スルーしようか迷ったけどどうしても気になって。
さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
たぶんPage fault利用のアーキテクチャに起因するもので、10年以上バグでは
無く仕様と主張しているんじゃないでしょうか。(推測)
＝＝＝以下、推測が合っているとして＝＝＝
普通製品でこんなことが起こったら致命的な障害としてベンダが認識して、ど
こかのバージョンアップ時に修正されるはずだと思います。
修正不可能だったら販売中止にすべきだし、R&D時に「原理的に修正不可能」
と判明したのだったら製品販売ビジネスをあきらめるはずです。その代わりに
開発請負ビジネスに変更して自社内利用に留めておくとか。
変なドライバを入れたらOSが落ちまくるので苦情の電話を入れたら「仕様です。
マウスはあまり激しく動かさないでください」と言われ、しかもそのままの品
質で10年以上も販売し続けているようなものだと思います。
「作ってたら何か出来ちゃった。出来ちゃったから売っちゃおう。動かしてど
うなるかは知らないけど。」と考え続けているように見えます。
技術的にも営業的にも、モラルに問題があるとしか思えません。
>さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
クライアントの話です。ただし、誤解のないように言っておくとメモリ
不足を捕捉して安全に終了するようにはできると思います。ただし、
どちらにしてもアプリケーションの続行は不可能なので、問題は問題
ですね。
…とここまで書いて、本当に合っているのか不安になったのですが、
ここでフォローしてもらうのは無理かな。
ああ、そういえばObjectStore付属のツールであるInspectorは、かなり
あっさり落ちます:-P
> クライアントの話です。ただし、誤解のないように言っておくとメモリ
> 不足を捕捉して安全に終了するようにはできると思います。
SIGSEGVをキャッチしたり、定期的にsbrkで調べたりとかでしょうか。自分が
作ろうとした機能のためにやるんならともかく、買ってきた製品のためにやる
必要があるんだったら相当使いづらいですね。
ドライバを作る繊細さで業務アプリを構築するような。明らかに一般公開する
レイヤを間違えている気がする。
Java版もあったと思うんですが、同じことは出来るのかな。
どっちにしろ業務中断になるけど。
> 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
> うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
> たもんじゃないということは更に上でも書いてます)
では何だったらいいのでしょうか？
> それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
> パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
> でしょ?
聞かれたから答えたのに。ｼｸｼｸ
> というようにシステム構成を考えていけば、で挙げたような問題点にぶ
> ち当たると思うんですが。
（１について）
別にRDBでもOODBでも同じ問題だと思います。
（２について）
確かにそうですね。
（３について）
そうは思わないです。ただのいちゃもんに聞こえます。
>・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
>なんて考えないでしょ?
言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
> 例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
> ・HTTPサーバをJavaで作った
> ・WebブラウザもJavaで作った
> とここまでは良いとして、
> ・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> なんて考えないでしょ?
>だとするとベンダの営業文句は根本的にはずしてる気がする。
ベンダの営業文句が根本的にはずして無かった事ありましたっけ？
> では何だったらいいのでしょうか？
それで今のところラッパーが世に出てきてるということでしょう。
将来もっと便利な解決策が出るかもしれませんが。
確認ですが、ここで展開されている議論はOODBを使うとか、言語オブジェクト
をそのままDBに入れる手法についてどう思うか、ということですよね。
「ラッパーで良い」、ということなら「そうですね」という答えになります。
少なくともObjectStoreの提供するアーキテクチャとかで書かれた「イン
スタンスのまんま（オブジェクトのまんま）格納や抽出なんかができれば」と
いう状況は、理想とはほど遠いと主張しています。
> 聞かれたから答えたのに。ｼｸｼｸ
では「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると
認識していたんだろう?」という質問をしています。
私の考えでは、「開発」の手法や便宜よりも「実行」の方が重要性が高いです。
＃もしかして「実行」と聞くと「コンパイル」をイメージしますか？
> （１について）
> 別にRDBでもOODBでも同じ問題だと思います。
最初に出来たオブジェクト指向設計・実装の成果が、たとえば５年間(償却す
る間)ぐらいはそのDBにアクセスするアプリケーション開発に強制的に利用で
きると考えて良いでしょうか？（開発環境はずっと同じと仮定）
分析あたりまではともかく、設計や実装は難しいんじゃないかという印象を持っ
ています。
私はアプリ実装の都合と関係のない設計の方が長持ちする可能性が高いと思い
ます。もちろんRDBにしたところで、いつの間にかフラグ情報が山のように入っ
てきて身動きがとれなくなってしまうことは良くあります。
変な情報が入りすぎてしまうと、きれいに作り直そうとも移行できなくなって
しまうでしょう。
> （３について）
> そうは思わないです。ただのいちゃもんに聞こえます。
これは私のプログラマ観（というか、オブジェクト指向屋観）なので、確かに
根拠や論理性がなかったです。_o_
> >・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> >なんて考えないでしょ?
>
> 言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
いいえ、HTMLとHTTPという言語とは関係のない便利なものがあるおかげで、い
ろんなブラウザから同じサーバにアクセスして同じ情報を閲覧できるようになっ
ている、ということです。
まぁ、表示が大幅に崩れたり、アプレットやスクリプトやフラッシュがどんど
ん入ってきて混乱した状況ですけど。
> ベンダの営業文句が根本的にはずして無かった事ありましたっけ？
「誇大妄想か？」と思うような表現はデフォルトですが、適用ジャンル・レイ
ヤを大幅にはずすことはそんなにないでしょう。
PhotoShopでVBスクリプトが使えるみたいですが、だからといってアドビが
「基幹システム開発に革命をもたらす！！」とか言ってSI市場に売り込み攻勢
をかけたら「アホか」と思うでしょ？
＃ODBCが使えるのかどうかは知らない。
>XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
DB全体で一つの文書、というのはまずないでしょうが、どの単位で一文書とするかは
設計次第ですね。
>・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
現状ではそのとおりです。
>・referenceは結局ID属性を使いまくりになる。
参照に関しては、XPointerやXLinkなどの技術がXML-DBに取り入れられるのを待つ必要
がありますね。
>・そのときの排他制御がどうなるのかいまひとつ分からない。
これは実装依存です。
>・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
XQL? XQueryのことですか? インデックスも実装依存ですね。
>なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
とはいっても、オブジェクトの変更に対する通知のみですので、RPC系技術の代替に
なるわけではありません。が、状態の変更をリアルタイムに把握する必要があるシステム
であれば、有効でしょう。
別にパソコンに限った話でもない。
将来、Javaに取って代わる言語が現れたとしたら、既存資産であるデータ（ＤＢ）
を使えるようなマッピングツールが出るであろう。でなければJavaに取って代わる
可能性はない。
それより先にそのDBMS製品が別のDBMS製品に取って代わられる可能性もある。
そのときに今までのデータの移し替えが容易にできなければならない。
では違うジャンルへのDBへの移行はどうであろうか。(RDBからOODB もしくは
OODBから次の世代へ）
移行できるかもしれない。コストにより移行が現実的でないかもしれない。
RDBではいろんな言語から使える。
なぜOODBはJavaだけなのか？ Java以外にオブジェクト指向言語が普及して
いないだけではないのか？
視点を変えてみる。
JavaではいろんなジャンルのDBMSが扱える。
実はそれだけの話なのかもしれない。
ベンダーの宣伝文句はベンダーの主張であり、アピールポイントです。
ですがそれが私たちユーザから見て、ベンダーの理想が実現するとは限らない。
なぜならそれはベンダーの理想だから。
Adobeの製品を使えば夢のようなデジタルでペーパーレスな世界が広がります。
マイクロソフトの製品を使えば、生産性が向上します。
別にどこのベンダーの製品でもいいですけど。
ほんとにそれが１００％実現した事がありますか？
身近なところで言えば、マイクロソフトの新OSが発表されるたびに、前回のOSのときも、
そのまえのOSの時も、同じ宣伝文句だったよなあとデジャブーを体感させられます。
いや、「100%で非の打ち所がないかどうか」ということではなくて、理想と主
張と製品機能はそんなにぶれてないでしょ?と書いたつもりです。
「100%実現してないからタコだ｣なんて文句言っても、あんまり意味無いと思
います。悪口言ってストレス解消するならいいけど。
理想に向かって少しでもマシな状況になれば良しとすればいいんじゃないかな。
上のObjectStoreの例で言えば
・クライアントサーバ構成をとっている。
・宣伝文句では基幹システム向けとかポストRDBというふれこみだった。(今も?)
・にもかかわらず言語依存度が高い。→拡張性に問題があると考えられる(CODASYL時代へ逆戻り)
・アーキテクチャに起因する問題がありそう(クライアントクラッシュ)
という点から、ベンダの理想と主張と製品機能がそもそも噛み合っていないと
書いたつもりです。
JavaしかサポートしていないOODBってなんですか?
ほとんどの商用OODBはJavaの普及以前から存在するのですが。
問題なのは、例えばJavaプログラムからストアしたオブジェクトをC++プログラムから
扱えない、とかそういうことなのですが。
>・クライアントサーバ構成をとっている。
これ自体には問題はないと思うのですが、何か問題ありますか?
> >・クライアントサーバ構成をとっている。
>
> これ自体には問題はないと思うのですが、何か問題ありますか?
書き方がわかりにくかったですが、箇条書きの１個目と２個目を受けて３個目
を書いています。
ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
しかし「クライアントサーバアーキテクチャ」といった場合には、アプリケー
ションが特定されないか、少なくとも数種類のアプリケーションは存在してい
るシステム構成を暗黙の前提としていたはずです。（Xサーバとかは又違う気
もしますが、ＤＢサーバを使った業務系システムということで）
ずっと名無しで書いているので、私のレスがどれか分かりづらくなってきたの
で、リファレンスをここで作っておくと、
,42,58,60,63,66-68,77,79,84,86,88
,93,94,99,101,103-105,112-114
,121-124,126,129,130,133
です。
(結構多いなw)
何人で議論してるのかも分からなくなってきたw
>ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
テクチャを想定していませんか? だとすると、それは勘違いですよ。それに
OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
アプリケーションでしか使えないなんてことはありません。
＃だから組み込み云々って話になっていたのか
> もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
> テクチャを想定していませんか? だとすると、それは勘違いですよ。
いわゆるサーバが起動していて、クライアントも実行されて、クライアントか
らサーバへリクエストが飛んで、その結果がクライアントへ帰ってくる、とい
うようなものを想定してました。Page faultでも似たようなものだと思ってい
ます。
「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
「クライアント/サーバ」に厳密な定義があるわけじゃない、別物だとしたら
SI市場に向けて「クライアント/サーバ」というメッセージを発信することは
やっぱり変だと思います。
＃話がうまく噛み合ってるかな?
> それに
> OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
> アプリケーションでしか使えないなんてことはありません。
> ＃だから組み込み云々って話になっていたのか
うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
で、そこから上の方で書いたような「設計の成果がどの程度の汎用性を持ちう
るのか」という疑問に繋がります。
この辺の感覚がどのぐらいなのか分からないのですが、安心して出せるガイド
ラインとか、｢どんなときにどんな風に使えばいいの?｣という疑問に対しては
「特定のアプリ専用」とか「組み込み」という感じにならざるを得ないのかな、
という予想です。
>「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
>うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
> そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
> 限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
その通りです。で、それを受けての箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
> >うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
> というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
> 意図です。
>
> だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
RDBMSでもそうした問題が皆無じゃないでしょうが、はるかにマシだと思います。
0 や100じゃないからみんな同じと考えるわけにもいかないでしょ?
○特定のアプリを想定せずに設計する(本当に何も想定しないのは不可能です
が、指向性としてベースの設計は)。
OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
その結果、例えばクラス構成をガラッと変える可能性よりも、正規化したテー
ブル構成をガラッと変える確率のほうが低いと思います。(←根拠となるデータは有りません。)
あるいは、クラスやその中の属性の永続性を意識しながら設計するノウハウが
一般的に浸透している状況なのでしょうか。
○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
RDB系では機構としては、追加した項目を使わないアプリはそのままでOKです。
これはOODBでは何らかのケアがあるんでしょうか?(Objectivityには何かあっ
たようなおぼろげな記憶があるけど勘違いかも。)
○更に、これは最近考えているんですが、RDB系ではクライアントがある情報
エントリを指定するためにコード(ID)やSQL文といった文字列を使うためにク
ライアント−サーバ間の結合度がlooseになっていますが、OODBでは変数名・
配列名・添字などがそれに相当しています。
そのためソース全体にわたってハードコーディングされた状態になっているた
め、クライアント−サーバ間の結合度がtightになってしまい、RDBに比べて柔
軟性に欠けて使いづらくなっているのではないでしょうか。
XMLを使えばもっとlooseになって接続の柔軟性が増すでしょうね。(今のとこ
ろクライアント−サーバ間よりもシステム間接続で人気みたいですが)
＃最後の主張は最近思いついたので、多分穴有りまくり。
>その通りです。で、それを受けての箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
「時代に逆行」というか、キャッシュアーキテクチャを取っているための
トレードオフと考えたほうがいいでしょう。キャッシュにロードされる
オブジェクトのトータルサイズが、キャッシュサイズに収まればいいわけ
なので、システム設計時にサイジングをきっちりおこなっていれば問題
ないわけです。
＃ま、理想論なのは承知しています
>OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
>○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
確かにObjectStoreでは大変でした。現バージョンでは改善されているかも
しれませんけどね。XPで有名なKent Beckは「日々のスキーマ更新」を
プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
はスキーマ更新が簡単なのですかね?
> 「時代に逆行」というか、キャッシュアーキテクチャを取っているための
> トレードオフと考えたほうがいいでしょう。
「キャッシュアーキテクチャ」を主眼にとっているのなら、やはり｢クライア
ント−サーバ」とはレイヤが異なっていると感じます。
どちらかというと「共有メモリ」とか「ソケット」に近いんじゃないでしょうか。
「システムをクライアントサーバ方式で構築する」とは言っても「システムを
共有メモリ方式で構築する」というのは違和感を覚えます。
｢共有メモリ」を無理やりシステム方式のレイヤへ持ってくるようなおかしさ
を上のキャッシュアーキテクチャでは感じます。
他のOODBではサーバへOIDをリクエストして、目的のオブジェクトをクライア
ントが取得すると思うので、こうしたことは当てはまらないと思いますが。
> OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
> 変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
その通り、変わりません。設計に問題が出やすいかどうかです。以下は私の感
じていることなのでプログラミング畑の人のほうが距離感がわくでしょうから
コメントが欲しいところ。
RDB系の場合、DB設計担当者が永続化に特化して作業します。また、機構上ア
プリの構造が入り込むことはありえません。
(だからアプリ設計者からSQLへの不満が出てくるわけで)
OODBの場合はどうなるんでしょうか?
アプリ設計者がDB設計者も兼ねるのなら、OO設計で永続性に注意してクラスを
区分するような設計が望めるのでしょうか。(これは上の方に書いたレコード
設計とジャンプテーブル設計に関する文化の懸念)
＃ObjectStoreの場合、どういう永続化設計をしなきゃいけないのかは知らないです。
永続化クラスを専門に設計する担当者がいるのなら、そのクラスを使うアプリ
設計者は設計の自由度が無いと感じたり、「作ったクラスがそのまま永続化」
というOODBが目指した利点を享受できないことにならないでしょうか。
その永続化クラス設計者はクライアントのアプリケーション特性、マシン環境
と共にサーバのマシン環境やネットワークにまで考慮が必要となり、求められ
る技術スキルがRDBと比べて驚異的に高くなってしまい、敷居が高くならない
でしょうか。
> XPで有名なKent Beckは「日々のスキーマ更新」を
> プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
> はスキーマ更新が簡単なのですかね?
GemStoneはSmalltalkベースですからC++ベースのものよりはやりやすいかもし
れませんね。(←単なる印象論)
XP(というかオブジェクト指向も含むプログラミング関連トピック全般)は「す
でに保存したデータ」に関しては何も考慮していないんじゃないでしょうか。
で、現実はそうもいかないからDBにアクセスしなきゃいけなくなって「面倒く
さいな」と不満が出る。
と聞かれたら
OODBに賭けるな。。
そうかもしれないけど、理由や考え方の経緯を書いてくれなきゃ議論のしよう
がないじゃん。
ObjectStoreだけじゃないかな。。
仮想メモリーを使って、そのままオブジェクトをPersistentにするって
Pointer-swizzlingだったけ？
ObjectOtoreが特許持ってるんだよね。
pointer swizzling という言葉を知らなかったのでググってみた。
永続ポインタを管理する手法のひとつで、類語として
hardware swizzling というのがあるみたいだね。
ええー、でもさ、「ページイン＆ページアウトを契機に
他のホストと共有しているメモリオブジェクトの整合性を図る」ってのは、
いろんな分散共有メモリ(Distributed Shared Memory)の実装で
利用されてる方法と認識してる。
複数ホストでポインタを含むデータを効率よく共有しようとしたら
必然的にそうなるのでは。
特許になってるとしたら問題かも。ほんとに特許になってるの？
RDBの考え方（表があればいろんなデータを貯蔵できる）は
数学の理論みたいなもんだから100年後も残ってると思う。
そのかわり問い合わせ言語はもっといいのが出てると思う。
SQLって確かIBMでしょ？昔はクエイルとかシークエルとか
いろいろあったらしいし。
オブジェクトDBの考え方は、「オブジェクトを払い出す」
という意味で分散オブジェクトの仕組みと統合されていくのでは。
そんでそれは分散共有メモリ（つまりホスト間での共有メモリ）とも
非常に近いと思うよのさ。
pointer swizzlingはOODB界隈では、メモリ上でポインタを辿る操作をディス
ク上での同等の操作へ置き換える、という文脈で使われていたと思います。だ
からObject Serverでも良いし、極端には裏でSQLが発行されていても良いんじゃ
ないかな。
「共有メモリ」の使い方としては、そこへread/writeするためのフォーマット
をアプリとは別に設計すると思っていたんだけど、分散共有メモリだとまた違
うんでしょうか。
多分｢共有メモリを分散する」時にPage Faultを利用するんじゃないかな。(詳
しく知らないけど)
アプリケーションのPage Faultを契機に動作するのは、より正確には「共有ス
ワップ領域」と考えた方が良いんじゃないでしょうか。そんな低レベルの機構
を表にむき出しにしてどうやって活用するのかいまいち分からないし、
ObjectStoreから何か提案されていた記憶もない。
今にして思えば｢クライアント･サーバ｣と言うよりも「P2P」と呼んだ方が近かっ
たのかも。(それでもP2Pでシステムを構築するイメージがつかめないけど)
特許に関しては、10年ほど前のパンフレットに｢特許出願中｣と書いてあるのを
見ただけで、実際に成立したかどうかは知らないです。
SEQUELが今のSQLらしいです。
ttp://www-6.ibm.com/jp/software/data/developer/column/iroha/23.html DBMSとして成立するには検索(インデックス)とトランザクション管理･排他制
御と運用支援が必須だと思うんですが、分散オブジェクト界隈ではそうした方
面のことは考えられているんでしょうか。
逆に言えばその3つさえあれば、アクセスするためのインタフェースがSQLでも
オブジェクトでもXMLでも後は好みの問題に過ぎないと思う。
それぞれの子が親へのポインタを持たざるを得ない。たとえば、伝票ヘッダと
伝票明細が 1:N の関係であるとき、伝票ヘッダには、従属する伝票明細へのポインタを
持たせることができず、伝票明細に親である伝票ヘッダの主キー(伝票番号)を持たせる、
という構造になる。そして、伝票ヘッダ(伝票番号=123)の明細を取得しようと思ったときに、
伝票番号=123 を持つ伝票明細を検索することで、親から子を辿ったのと同じ結果を得る。
これは、データを横断的に検索できるという RDB-SQL の特性を利用してはいるが、
本来の横断的なデータベース検索とは本質的に異なる。
親が子の情報を持てないために、検索機能を利用しているだけで、
2004/08/01〜2004/08/31 の伝票明細を検索するなどの横断的検索とは違うのである。
これが、オブジェクト指向になると、もっと直感的に設計ができる。
つまり、親に子の情報を持たせることができる。コレクションなり配列なりを
使用することによって。
オブジェクト指向(言語)では、現実の事象をオブジェクトとしてモデリングすることを
身上としている。これは非常に直感的で分かりやすい構造を維持できるからだ。
対して、RDB では利用方法を想定して、非直感的な設計を余儀なくされることがある。
上記の子に親のポインタを持たせるというのは、そうしないと辿れなくなってしまうから、
そうしているのであって、現実の事象を直接的にモデル化しているとは言いがたい。
トランザクションをサポートしていないデータベースなんて使えないですよ:-)
インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
と思います。また、排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
最悪デッドロックの嵐になります。
「共有スワップ領域」はお見事。頂いとく（笑
サンQueue。
の言うことは確かにうなずける。勢い込んでうんうんとやってしまった。
ところがを見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
おいらは階層型DBもネットワーク型DBも触ったことないんだが、
当時遅いと言われたらしいRDBがなぜこれだけ発展して、
前記２つがなぜ廃れたか、誰か知らないかな。
手元のモデリング本も参照してちょっと想像してみたのだが、
階層型：無理にでも木構造にしないとだめ。表現力乏しい。
→XMLDBもそうじゃないか？
ネットワーク型：表現力ありすぎ、複雑になってメンテ困難。
well formedな形についての理論が未完成。
→オブジェクトDBもそうじゃないか？
うーむ、もしかしたらリレーショナルの良さは程ほど具合？
直接ポイントできるのは親方向だけで、
子方向には検索という形でしかポイントできない、ということに
結構意味があるのかも知れないなぁ。
著者イラストが若すぎる気がしないか？age
設計というよりも実装の話ですよね?
オブジェクト指向でも親が子の情報を持つわけではなくて、子へのポインタを
持つだけなんじゃないでしょうか。設計において親子関係であることを定義す
ることって出来ましたっけ?(継承時にサブクラスであると宣言するように。)
設計者と利用者の間で合意を取っているだけだと思います。
RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
「left outer join」に相当するわけだし。
OODBだと単純に持たせただけだと、子から親へ辿るのがめんどくさくなっちゃうでしょ?
特定の明細件名をもっている伝票番号一覧を出すとか。
＃双方向リンク用のライブラリ等がどのぐらい普及しているものなのかはよく
知りません。
オブジェクト指向でも「期間を限定した伝票明細の検索」は、「検索」機能を
利用するでしょう? キーを指定してサーバへリクエストする代わりに、属性
名や配列の添え字がソースコード中にハードコーディングされているし。
＃私はRDBのjoinとOODBのpointer traverseは設計上の意味合いはほぼ同じと
＃考えているけど、ここは合意が取れるのかな。
RDBで明らかに足りない、あるいは普及していないのは、型チェック機能など
でしょうね。
IDの更新に対する保護機能も無いし。
> トランザクションをサポートしていないデータベースなんて使えないですよ:-)
だからインタフェースよりもそっちの方が重要だし、コンパイラに渡す文字列
を書きやすくするためにそっちへしわ寄せが行っていないか、十分検討したい
です。
> インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
> と思います。
ObjectStoreの「コレクション」は普通の意味とニュアンスが違っていたよう
な。Collection型とかとは違うんですよね?
> 排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
> 単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
> するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
> 最悪デッドロックの嵐になります。
＃クラスタ単位がどのようなものか分からないので外しているかもしれませんが。
「仮想ページがそのまま」というのから想像すると、コンパイラをhackしてヒー
プ領域の使い方を指示できる、という理解で良いでしょうか。
そこまでする必要があるなら「プログラム実行イメージをそのまま格納」と言
うだけのためには、あまりにも汚くて他の部分への負担が大きいように思います。
Page Faultを契機にしたPage Serverにこだわるよりも、pointer traversalを
契機にしたObject Serverの方がまだ使いやすそうな印象を受けます。
> ところがを見て思ったのは、双方向にリンクできると
> 設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
いや、それよりもPage Serverであるがゆえにロックがページ単位となり、コ
ンパイラが仮想ページの中にどのようにオブジェクトを配置するかを理解する
必要がある、ということではないでしょうか。
> おいらは階層型DBもネットワーク型DBも触ったことないんだが、
> 当時遅いと言われたらしいRDBがなぜこれだけ発展して、
> 前記２つがなぜ廃れたか、誰か知らないかな。
はるか上のほうでも書きましたが、UNIX・クライアントサーバブームが訪れた
ときに、そのプラットフォーム上でCSモデルを構築できるのがRDBしか無かっ
たからではないでしょうか。で、Oracleなんかはその流れを逃さずにホスト版
のOracleをUNIXへ移植して売り込み攻勢をかけたと。
だからOracleのコマンドラインツールはUNIXっぽくもWindowsっぽくも無くて、
なんか変な感じでしょ?(もう何年も触ってないけど)
他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
ところがを見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
ページロックしかサポートしていないRDBMSで、一つのページに複数のテーブルの
レコードがランダムに存在している状態を想像してみてください:-)
同意します。オブジェクトモデルをデータモデルに落とすのは、それほど難しく
ありません。もちろん再帰的な構造を持つものなど、悩ましいものはありますが。
RDBがいいのは、テーブル間の物理的な関係が疎なために、アドホックな参照や
メンテナンスがやりやすいことですね。
汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
ですが。
>他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
C/S全盛の時代より前にありましたよ。
>
> 汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
> Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
> ですが。
探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。
ttp://infoboerse.doag.de/mirror/frank/faqora.htm#HIST > C/S全盛の時代より前にありましたよ。
でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな？
トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。
>探してみたら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はそれに乗り遅れた、と。
実装(制限)に合わせた設計を要求されるということある。
これは、実際のデータモデリングとは異なるスキーマ定義を
しなければいけなくなることがある、ということを意味する。
> RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
> ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
> 「left outer join」に相当するわけだし。
left outer join を使うこと自体がトリックなのである。
left outer join はポインタを辿る操作であるが、A left outer join B とは
"A から B を辿る" ことを意味する。 で例示した問題では、
"伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
これは、子から親を辿っていることに他ならない。
ここで、ひとつ考えてみて欲しい。その元となる子(伝票明細)の集合は
どのようにして集めるのだろうか？ 伝票番号=123 を取り出したいとき、
伝票番号=123 を持つ伝票明細を取り出し、外結合によって伝票ヘッダを
辿ることになる。これは明らかに問題が前後している。伝票ヘッダを辿る前に、
伝票ヘッダの主要素である伝票番号を伝票明細は利用しなければならないのだから。
RDB の設計に慣れた人間ほど、この問題を意識することができない。
得たい結果から、無意識のうちに RDB式のスキーマ設計を行えるようように
訓練されてしまっているからだ。
この伝票問題の設計において、ルーキーが次のような愚かな設計をすることがある。
伝票 1枚あたりの明細数が最大10明細であると決めうち、伝票ヘッダに
伝票明細1行目, 伝票明細2行目, ･･･, 伝票明細10行目 と子へのポインタを
持たせてしまうのだ。これは RDB の設計としては明らかに誤りである。
正規化されていないために、商品A を購入している伝票を検索することが
できなくなってしまうのだから。
しかし、この発想を頭ごなしに否定してはいけない。この発想こそ直接的モデル化なのである。
発想自体は非常に分かりやすく直感的なものである。ただ、RDB においてはスキーマで
表現できないために、「誤り」として否定せざるを得ないだけのことである。このルーキーの
設計を馬鹿にする前に、この発想を直接的にモデル化できない RDB の制限についても
考えてみてもらいたい。RDB がモデル化において完全ではないことが次第に見えてくる。
もうひとつ例題を示そう。
私、山田太郎には複数の子供がいる。さて、山田太郎の子供を探してきて欲しい。
この世界の住人には同名の人は存在しない。RDB に慣れ親しんだ人達は、迷わず、
select 名前 from 住人 where 父親の名前 = '山田太郎' と書くだろう。
間違ってない。結果は正しい。しかし、あなたは、この正しい結果を得るために
信じられないほどの労力を使ったのだ。信じられない？ 簡単な作業だったって？
そんなことはない。自分自身が DBMS になったつもりで上記のクエリを噛み砕いて
実行してみて欲しい。あなたは、世界中の住人を訪ねて周り、「あなたの父親は
山田太郎ですか？」と尋ねなければならなかったのだ。これは、山田太郎の子供を
探すために、世界の住人すべてを走査しなければならないことを意味している。
もちろん、実際のデータベース実装では索引が利用されるため、全住人への
物理走査など発生しない。それは分かっている。ここで考えて欲しいのは、
概念としてどうかということだ。たとえ物理走査が発生しなかったとしても、
論理的には全件走査が行われたのである。DBMS は「全部調べた結果、山田太郎を
父親に持つ人達はこのだけです。」と結果を返すのだから。
「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
「そんなことはできない。」と、あなたは笑うだろう。世界中を旅して周ることに
なんのためらいも持たないのに、本人に聞く事はできないという。
滑稽ではないだろうか。これが現在の RDB なのである。
これに気付かない人は多い。索引によって世界中を旅して周る(のと同じ結果を得る)
など、あっという間にできてしまうからだ。時間はまったくかからない。
時間はかからないけど、世界中を旅していることは理解して欲しい。
> "伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
なぜでしょう？
伝票番号は明細にだけ存在して、ヘッダには存在しないということでしょうか？
良く理解できないんでどんなデータ構造と参照処理をを想定しているのか、も
うちょっと詳しく教えてもらえませんか？
> 「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
山田太郎さんを特定するには、オブジェクト指向ではどうなるんでしょうか？
>まだ RDB の問題を理解できていないだろうと思う。
>もうひとつ例題を示そう。
どこに問題があるのか書いてもらわんと意味がわからんのだが。
もちろん記述としては、"伝票ヘッダ left outer join 伝票明細" と
書くこともできる。しかし、この記述は外部キー定義に則していない。
伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
ここでは、山田太郎をポイントする方法を問題とはしていない。
OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
たとえば、横浜市在住の40歳男性にちゃんねらDB板常駐という条件で、
山田太郎が見つかったというストーリーにしたら、満足するだろうか？
とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
RDB ではモデル化が直接的でなくトリッキーな方法で実現しないといけないことがある、
というのが現在の RDB の問題である。これは、実装技術により速度的にはなんの問題もない。
だが、概念としての難解さを抱えているのである。
select 名前 from 住人 where 父親の名前 = '山田太郎'
もう一度、これを見て欲しい。実装や速度の話をしているのではない。
「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
「山田太郎の子供を探す」という命題が「住人すべての中から山田太郎を父親に
持つ人を抽出する」としか記述できないのである。これは本質を、RDB の性質に
合わせて書き換えているということであり、可読性の低下をもたらしている、とも言える。
この RDB の性質に合わせた問い合わせの書き換えについては、可読性の低下だけでなく
誤った結果を得てしまうというミスにつながることも少なくない。このミスの発生については
また改めて名寄せに類似した問題で説明することにしよう。
> しかし、この記述は外部キー定義に則していない。
なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
操作における参照方向を定義したものじゃないと思ってたけど。
「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
それは参照方向の定義だ」という主張でしょうか？
> 伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
> 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
それで良いと思うけど。OIDならそれを回避できるわけじゃないですよね？
OIDが物理アドレスに簡単に変換できるかどうかというのはまさしく「実装」
の問題ですよね？
>
> OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
変だと思うけど。
> とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
よい、ということでしょうか？
>実装や速度の話をしているのではない。
>「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
>これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
そうなの？実装されたプログラムの速度が問題なのかとおもってた…
速度が問題じゃないなら、あなたがやっかいさを指摘してるのは「関係代数」なのか。
そこまでくると話が発散しそうだな。たとえば行列演算や基礎物理が理解できないやつに
ポリゴン使った3Dゲームのプログラム任せられないのと一緒で、
関係代数のエッセンスをつかめないやつにRDB使うプログラム任せるなってことに
なってしまう。
それとも、ORマッピングなんて所詮ムリヤリな話だからオブジェクト指向の
大事なメリットを損ねるのよ、だからプログラムをOOでやるなら
DBもOOでやれよって話？
> 操作における参照方向を定義したものじゃないと思ってたけど。
外部キー定義とは、データ走査における(推奨される)参照方向の定義である。
これに従わないものは「辿る(外部参照)」という行為ではなく横断的検索である。
なぜなら、外部キーの性質により順方向の参照は、必ず 1件の結果となるが、
逆方向の参照結果が 1件になることは稀だからである。
> 「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
> それは参照方向の定義だ」という主張でしょうか？
主張するつもりはないが事実としてそうである。伝票明細は商品への外部参照を持つ。
これは、「伝票明細から売り上げた商品を知ることができる」ことを意味する。
商品から無数に存在する伝票明細への参照というのはモデル化として、おかしい。
> > 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
> それで良いと思うけど。
「伝票明細全体から探す」ということに疑問を感じないのであれば、
私は、もうこれ以上あなたに説明するだけの言葉を持っていないということだと思う。
> だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
> 変だと思うけど。
> つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
> よい、ということでしょうか？
申し訳ないが、これらの質問の意味・意図も理解できなかった。
あなたは何をしたいのか？
これだけは否定しておいたほうがいいだろう。私はモデル化の制限について話し、
これらが実装の問題でないことを説明してきた。だが･･･今までの私の説明と矛盾するようだが、
もっとも重要なのが「実装」なのである。なぜなら、実装を差し置いて(理想的なモデル化論だけで)
システムを組み上げることはできないからである。
つまり実際に使用できる実装を考えた場合、現時点では RDB を選択するのが
もっとも良いと私自身考えている。ハンドリングが Java などの OOP であったとしても
バックエンドには、現時点で RDB を選択すべきなのである。私は OODB を推したりはしない。
ただ、いまの RDB が 100年続くとは思って欲しくない。私が指摘したように
うまくモデル化できない事象もたくさんある。これらを真面目に考えていくことは
RDB のブレークスルーになるかもしれないのだ。
私は167ではないけど、まぁもちついて。
167が言ってるのは…DBMSのメリットのひとつ
[特定のデータ操作からデータの内部構造を独立させることができ、
その独立性によって仕様変更に対する柔軟性が向上したり、
他のクエリに対しても同じような速度でアクセスできるという期待を持てる]
をあげてる。
特定の操作に対する最適化は、それはそれでアリだけど、
それを持ち出してきてRDB、というか関係代数が問題を含んでいる
というのはちと飛躍かと。
あと、１：Nの例を挙げてるけど、現実世界がN：Mになっててそれを
率直にモデリングしたい場合もあるわけで。関係代数のメリットって
それを中立的に表現できることじゃないの？
それから気になったこと。
やろうと思えば親１：子N関係でも親から子へ、子の数に関係なくリンク張れるがな。
C言語なんかではN分木を、「長男と弟へのリンク」の２分木として実装するでしょ。
それと一緒。伝票ヘッダは商品１へのリンクだけ持ってて、商品１が
商品２へのリンクを持ってればすむ。
あなたならディレクトリ構造みたいな木をどうやってコーディングするのさ？
そんでそれは、関係代数マンセーな視点からは「最適化に含まれるので
別議論である」ってこと。
あなたたちは、まだ理解が追いついていないようだ。
もうちょっと説明してあげたいこともあったのだが、的外れな質問で
話が遮られるばかりなので、ここでの説明はこれで打ち止めとしよう。
非常に残念なことである。
あなたたちには、これからももっとがんばってもらいたいものである。
あまり論点が明確化されてなくて探りを入れることになったので、質問が的を
はずしていたかもしれないのはしょうがないですね。
＃全くの他人とは、あまり議論されたことが無いのかな？
私は結局論点にしたいのがモデルなのか、DB利用者にとっての実装か、DBMS自
体の実装か、利用する上でのシンタックスなのか分からずじまいでした。
もう止めるということなので残念です。どなたかにあった「外部キー定
義とは、データ走査における(推奨される)参照方向の定義」というのが分かる
Webサイトか何か知りませんか？
＃もう今の環境じゃDB関連の書籍が手元に無い、、、
私の頭の中じゃ、外部キー定義はレコードが参照して整合性を保つためのもの
で、アプリがその参照を参考にしながら逆方向に辿るのは全然OKだと理解して
た。
逆向きに使っちゃいけないのかどうかは知らんけど。
スキーマとして依存関係を記しているというのもうなずける。
話の意味は良くわかんないんだけど、読み物として面白いから
山田太郎先生には返ってきて欲しいぞ。
DQNに取り憑かれ易いよなぁ。
D どんな
Q クエリも
N ぬるぽで返す〜
ときたもんだ
∧＿∧
（ ´∀｀） ＜ぬるぽ
分散環境で高速参照が必要なところで使ってみると面白いかも。
は @it の記事のことですかな？
私はいまODB勉強中なのですが、
確かに面白いかも…
しかし、ううむ…。あの記事、なんか論調として
・RDBを扱える技術者は豊富
・RDBは壊れたときのリカバリなど実績がある
・間にはさむキャッシュとしてObjectCacheをつかうと速くてｳﾏｰ
というように読めたのだけど、それって、
RDBでスピードが出なかったときの
最適化の選択肢なのかな？いやまてよ、
ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
ObjectCache使ったアプリ書いたひといる？
アプリの書き方変わらんの？
これって、EJB-RDBひとまとめにしてDBと考えると、
「EJB+RDB=OODB!! カモンOODB!!」
などと思うのですよ。
本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、
データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
何かないでつか。
> これって、EJB-RDBひとまとめにしてDBと考えると、
> 「EJB+RDB=OODB!! カモンOODB!!」
> などと思うのですよ。
RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
ないでしょうか。
> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
> 何かないでつか。
MATISSEが多少近いかもしれません。meta-schemaをいじれるようになっている
らしいので。
しかし、ユーザに提供しているインタフェースと、DBMS内のモデル・検索処理・
トランザクション管理・排他制御・ディスクページ内レイアウト・ロギングが
密接に関連しているので、完全にフリーにするのは難しいと思います。
RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
合には大抵ライブラリやラッパーをかぶせて実現しています。
無理やり実現しようとすると結局ファイルシステムと大差ないものになってし
まう気がします。
レスどうもです。
うーん、考えがまとまってないので少しだけ。
>RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
>する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
>が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
>ないでしょうか。
・・・中略・・・
>RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
>合には大抵ライブラリやラッパーをかぶせて実現しています。
ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
実のところ、既存のoodbは適当な記事に書かれている程度しか知りませんが、
オブジェクト指向のメリットの一つは、データモデルをカプセル化できること
の筈。なら、そのようなDBがあればべんりかな、と。裏側で動いているRDB
のデータモデルも、裏側で検索やっているBLAST*も隠して、同じように／横断
的にアクセスできるとけっこう有り難い・・・。
*blast うちらはcgiでやることが多いのですよ、これ。以下参考；
ttp://www.ddbj.nig.ac.jp/search/archives/homology_doc-j.html > データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
フリーって何のことか補足ｷﾎﾞﾝﾇ
>@it の記事のことですかな？
そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック
エンドに使えるとは知らずスルーしていました。
>ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。
ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで
O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー
マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決
できるんじゃないかな、と思います。
交換可。データモデル等からある程度自由になりたいの。
プラッガブルとか書いた方が良かったかな。
EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。
> ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
> oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
もともとDBMSの類はデータを公開して共有しよう、というところから生まれて
いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま
ま当てはまらないところもあると思います。
カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、
いったんDBに格納した過去のデータは簡単には変更できないという違いもあり
ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど)
アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
利かもしれません。
アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、
・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース
をどうやって定義するのか。
・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部
分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。
辺りが悩ましそうです。考察するのは面白そうだけど
パッケージや製品として世の中に出す場合には、システム非依存にしなければ
ならないところも難しい点だと思います。
逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。
(それも特定の業務「モデル」に縛られることにはなるけど)
＃勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな？SAPもそうだっけ？
>アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
>えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
>利かもしれません。
入れ替える、というのが不適切な表現だったようです。
想定している応用はこんな感じです。
1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。
2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。
3.xmlなグラフデータも検索したい。
4.検索結果をオブジェクトとして受け取りたい。
ですので、入れ替えるというよりは組み合わせて使うような。
それだとデータモデル横断的な検索とかできないから何かないか、
というのが180の後半です。
やっぱり
182>ライブラリやラッパーをかぶせて実現
とかObjectCache'とかじゃないと余計悩ましそうですね。
クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ
ならないんじゃ実運用に耐えない。
ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
またRDBであれば、他システムとの連携が簡単（ODBC,EAIなど）だが、インタフェースが
独自のODBではそれも難しい。
ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や
保守運用時には全然メリットを感じない。
ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
分散キャッシュでのスケールアウトもOracleのRACの方がまし。
ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは
全く感じられない。
(今までの書き込みを見てもらえばわかるけど)大半は同意。
>ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
>ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために
クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では
OODBを積極的に使うほどのメリットには思えないけどね。
>しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
クラスタへの配置とか?
>メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
特に最近はＤＢサーバ上のストアドが高級言語になりつつあるから、余計ＯＤＢの
メリットが少なくなる。
ＣＰＵ技術が、これからマルチチップ、マルチスレッド＋仮想化進むので、
わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、
運用保守費が増加するだけと思います。
>キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
>クラスタへの配置とか?
クライアントキャッシュのサイズなどです。
確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。
キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。
ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、
それはRACでのスケールアウトでも達成可能。
でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。
個人的には、SQLServer2005のようなストアドの高級言語化の方が、
ODBよりも良いと思われる。
ChacheのようなアプローチもObjectStoreよりかは良いですね。
いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より
値検索の方が多いので、ODBの出番はない。
> それだとデータモデル横断的な検索とかできないから何かないか、
> というのが180の後半です。
なるほど。
昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい
だけど、頓挫したのか普及しなかったのか、、、
今はそれ以上にいろんな検索がありえるし。
全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、
後はアプリケーションでがんばってね、とか。
結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。
・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定
・インタフェースはOODBを参考に
・引数等で各バックエンド固有の機能を記述することは極力避ける
というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事
はしていないなw
.NETとかは一応この方向を目指してるんだっけ？
ほぼ全面的に同意ですが、
> クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
> ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思
えないです。
また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの
なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。
OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ
に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛
いですね。
HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し
かないですし。
ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作
したんだろう？
とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく
出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする
と１インスタンス＝１レコード といった単純な格納の仕方が通用しなくなる
ので、かなり頭をひねらなくてはならなくなると思います。
そういったことを考えると、ODBといったものの方が自然に扱えていいと思う
のですがいかがですか。
ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ
クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に
そうだし、他のOODBもそれを志向しています。
そのためプログラミングは便利になるかもしれないけど、システムを稼動させ
たときの運用などにしわ寄せがよってしまいます。
どちらがクリティカルかといえば、動かしたときの方だと思います。
- オブジェクトをアプリケーションから透過的に永続化したい
というニーズと
- オブジェクト指向設計に即したデータストアのインフラが欲しい
というニーズは似て非なるものですよね。
現行の製品はもしかすると前者からスタートしているのでしょうか。
だとすればあまり魅力を感じません。
むしろ欲しいのは後者です。今後に期待したいですね。
ZopeのZODBなんかは、前のやつそのものって感じですね。
Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの
ように扱える反面、Pythonからしかアクセスできないみたいですね。
データベースに格納したオブジェクトが、例えばCORBAのような
汎用のインターフェースを通じてリモートオブジェクトとして
アクセスできるような製品はないんでしょうか。
CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し
てCORBA側が対応したのかな？
だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく
知りません。
そもそもPOS自体が企画倒れになったらしいから、あまり（CORBAとしては)力
を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか
な。分散トランザクションもややこしいし。
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。
POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。
> CORBA自体が下火だからでしょうか。
結局水平分散はコンセプトとしては美しいけど、方式設計や運用設計が難しかっ
たんですかね。
だからといってEJBや.NETの世界に行っても、ヘテロジニアスなストレージレ
イヤの水平分散・統合が簡単になることもなさそうと思ってるんですけど、実
際どんな感じなんでしょう?＞使っている方。
Entity BeanやEJBの分散トランザクション管理機能(DBMSにdispatchするだけ
じゃなくて)がここまで進化した、というような話はあるでしょうか?
ttp://www.atmarkit.co.jp/fdb/single/01_rfid_database/rfid_database01.html RFID、ECサイトに求められるデータベース性能とは？
>バックエンドのRDBMSはそのままに、
>フロントエンドのデータ・キャッシングに「ObjectStore 注」のファミリ製品であるObjectCacheを導入することで、
>Linuxマシン上で稼働する4つのObjectCacheインスタンスにリプレイスでき、コストを大幅に削減できました
>同期処理時間は12時間から1分以内に改善され、応答速度も向上しています。
理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？
> 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？
使っているのはOODBじゃなくて、キャッシュでは?
機能を想像してみると、RDBのデータをどの単位か分からないけれどフロント
エンドマシンにキャッシュして、OOPLから透過にアクセスできる、というもの
じゃないでしょうか。
RDBMSのデータキャッシュページと連動させていたら結構すごい機能だと思う
けど、やってるのかな。
ディスクじゃなくてメモリにすれば、そりゃ速くなるでしょうね。
「同期処理」とか注文処理のトランザクションの内容やタイミングが分からな
いから、どの程度キャッシュの賢さが効いているのか分からないけど。もとも
との設計がタコだったのかもしれないし。
数年前のシステムを公開しているのだと仮定すると、当時と比べればIAサーバ
の性能も上がってコストも安くなってるだろうし、Linuxも最近ようやく使い
物になってきたし。この辺はObjectCacheとは全然関係ないですね。
ところで、ObjectStoreっていつの間にか買収されてたんですね。3年ぐらい前
はXMLブームに乗って「今後はXMLに特化した製品・会社になる」と宣言してい
たような気がしたんですが、最近はEC・リアルタイムに特化なんでしょうか。
自宅ではMacOSXなので動かん。どうしょ。
想像のとおりで、このアイデアには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はニッチな市場しかないじゃないかな。
OracleのSQL*Plusとか、それこそAccessみたいな感じのビューワってあるんでしょうか？
（簡単にデータの格納状態がエビデンスとして見れるツールがないと開発には使えない）
まぁ仮にそういうツールがあったとしても、おそらくそういったビューワでオブジェクトを参照できるようにするためには
そのオブジェクトがOODB製品が提供する独自のツール表示用interfaceを実装する必要があるとか、
そういう仕組みがあるのでしょうけど。
例えばOODBの提供するinterdaceを実装することで、複数の言語への（ある程度の）マッピングをOODB側が
自動的に行ってくれるとか。
そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。
RDBで分散キャッシュができれば、現状のOODBの意義はほとんどないと思います。
ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
想定されているのなら、そういうものはないでしょう。
Objectivityは言語非依存のようです。また、Cacheもそうですよね。
関連付けたりするの？
あと関係型（RDB）のSQLや階層型（例えばXMLDB）のXPathに相当する問い合わせ言語がないというのは
むしろOODB的にはデメリットだと思うんだけど。
条件付きの検索というのは業務では必須だし、そもそもユニークIDだけで一意にモデリングできるものって
世の中にはあまりない。
検索機能がないのって、例えば履歴書10000枚をキングファイル10冊目にまとめて前に置かれて、
「このキングファイルの中の履歴書にはすべて一意の番号がふってある。
目の前に置いてあるからわざわざ取りに行く必要はない。
さあこの中から○×の条件にあった人材を捜せ」
といわれているのと同じような気がする。
ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。
> ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
> もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。
ODMGは企画倒れになったけど、少なくともVersantにはQuery Languageが有りました。
VersantにはSQLラッパーみたいなのが有って、ROマッピングも出来たように覚えてます。
（5〜6年前の記憶）
おまじないカラムを使ってJOINする命令を投げるとと、DBMSではpointer
chasingしてくれるという面白いインタフェースです。
もともとOODBには「Query Languageが欲しければ自分でいくらでも好きなよう
にプログラムすれば良い」という発想が最初にあったように思います。
でもそれじゃ使いづらいから各社とも付けてますが。
さすがにアーキテクチャ上一番なじみにくそうなObjectStoreでも属性値を指
定して全件検索することぐらい出来るんじゃないかな。
> ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
> の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
> 想定されているのなら、そういうものはないでしょう。
RDBの「汎用ツール」にしたって、ユーザに公開しているプログラミング用の
インタフェースを使って出来ているでしょうから、OODBが特に使いにくいとい
うこともないのでは。
あ、RDBだとSQL*Plus見たいなものを自分で作ろうと思えば作れるけど、OODB
だと相当面倒なことになるんでしょうか。
「Inspector」を使うためには開発したクラス定義ファイルを読み込ませてや
らないといけなくて、Inspectorの中ではかなり高度なことをやっているのかな。
> そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
> 後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。
こうした、「要するにプログラムの中の変数を保存すればよいんでしょ？」と
いう発想が、そもそもOODBや一部オブジェクト指向技術者の間違いだと思いま
す。
＃207さん失礼。
もともと「データ」はコンピュータを使う前から現実に存在していて、それを
コンピュータでどうやって管理するか、という考えからDBMSが出来ていると思
います。
少なくともトランザクション管理や排他制御などを備えたDBMSは、暗黙的にそ
うしたことを想定しています。
その点でコンピュータが出来てから発生した画像ファイルとか文書ファイルを
「ファイル→名前をつけて保存」するのとは全く違います。
これは「プログラミング」のみに着目して、プログラムを実行してどうするの
かを全く忘れ去ったために起こった履き違えだと思います。
に出てくる「インピーダンスミスマッチ」も確かに存在するのですが、「インピーダンス
ミスマッチ」を理由に履き違えによる本末転倒が広まってしまった気がします。
＃OODBがあんまり好きじゃないから、ひどい言い方になってるなぁ、、、
オブジェクトの永続化は変数の保存とかファイルのセーブなどとは
違う水準の発想だと思うけど。
「オブジェクト」はコンピュータを使う前から現実に存在している
もので、オブジェクト指向設計はそれをコンピュータでどうやって
管理するか、という考えだし。:-)
＞「オブジェクト」はコンピュータを使う前から現実に存在している
いやーそういう原理主義は今は流行ってないよ。
オブジェクト指向主義者のいう「オブジェクト」って
似たり寄ったりの概念だよね
コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。
私にはそうした意味の「オブジェクト」とは非常に抽象化された概念で、「○
○すること」「○○するもの」と呼べるもの全般を指しているように思えます。
それはDBMSを使った実装とか開発等とは全然別のレイヤの概念で、それに無理
矢理「オブジェクト」と同じ呼称を付けて一緒くたにしているんじゃないでしょ
うか。
「オブジェクトの永続化」と「変数の保存」がどのように違う水準で議論
･考察・活用されているのか教えてください。
＃クレクレ君ですいませんが。
ttp://www.db4o.com/ ｷﾀ━(ﾟ∀ﾟ)━!
SQLじゃないよね？
cacheかな。何せ使った事がないもんですみません。
OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。
格納するときはいいけど、selectとかしたらどうなるの？
beanの型でデータが返ってくるのですか？
（だとしたら、joinとかしたらどうなるのだろう･･･
新規のbean型を動的に生成するのだろうか？）
要するにオブジェクトを永続させたいのか。
データベースの主張するところはとどのつまりデータの独立だった。
ここのところはどうなるか。それで唐突に思い出したのだが、
IBMシステム38がサンノゼ研究所で1970年代に開発された時、
最大の課題は「停電」だった、と言う話。
このメモリー(プログラム)とデータベースを一体に見ようとした
システムでの課題はデータの永続性だったということ。
(偏見に満ちたレスです。)
ODBとOOPLを考えるときに、アーキテクチャ全体がどうなっているかとか、
システムがどういう風に稼動・運用・活用されるのかということを考えてはい
けません。
目の前のエディタに表示されている作成中プログラムのコードだけに着目しま
しょう。オブジェクト指向で楽しくプログラミングしているのにSQLとか変な
ものが混ざってきて嫌ですよね。
そこで全てを｢オブジェクト｣にしてしまえば解決してしまいます。
SQLなんてコンピュータの都合で産まれたもので、それに比べればオブジェク
トというこの世に昔から存在しているものを活用すれば、全てがうまくいきます。
「データの独立性が云々」なんて考える必要はありません。
だってそもそもやりたいことはプログラミングなんだし。プログラムのおまけ
のデータなんて、適当にディスクへ吐き出しとけばいいんです。
仕事はコンパイルまでで終わりだし、論文や文献の実証実験にもなって一石二鳥ですね。
＃一応「皮肉」で書いたつもり。OODBの利点を熱く語る人がいないとネタになっちゃうなぁ。
>SQLなんてコンピュータの都合で産まれたもので
SQLは論理式(まがい)です。オブジェクトを認識できるものが
論理から超越していることはあり得ません。
あなたの文章はしっかりしていますし、十分に論理的です。
やっぱり現時点では具体的に使えそうな業務というか適応分野があまり見当たらないよ。
（別部署のシステムでGemStone＋Smalltalkというシステムが1つあるけど、必然性を感じない）
それこそかつてのJavlinのようなEJBキャッシュみたいなニッチなところ（業務そのものの
データではなく、極めて基盤的なところ）にしか入り込めないという印象。
逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。
オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。
SQLは集合の性質を記述するもの(内包的な定義)。
システム38ですね。良かれ悪しかれ興味深いマシンでした。
データについては、表現方法を妥当なレベルで共通にできる。
しかし手続きは、言語や処理系によってその表現は異なる。なかなか共通させることはできない。
「オブジェクトの表現形式」を標準化し、それをいろんな処理系からアクセスできるようにする作業が必要になる。
で、それは技術的には可能だ。
だが実際問題としてそこまでやる必要性が薄い。
単にオブジェクトデータベースを使うだけならいつでもできるが、
広い普及はまだまだ無理な状況にある。
Newtonのsoupとか、BTRONみたいなものかな？
データはオブジェクトごとに異なりますが、手続きは変わりませんよね。
オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。
また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、
むしろ手続きは永続化対象外でであるべきかと思います。
データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル
モデルに変換するひつようがないのであれば価値があると感じます。
ストアドとかトリガみたいな機能が必要になったことが、
データと手続きが不可分であることを表していると思うのだが
実装(プログラミング)のためにはそうした方が便利という面はあると思う。
だけど実装のために必要になったデータ(ループ変数とかフラグとか関数間受
け渡しための変数とか)と、業務で必要なデータ(顧客名とかIDとか単価とか)
は概念上別なものとして認識するのが自然だと思うけど。
OOな人は何故か「とにかくプログラム上は一緒なんだから」という考えのよう
な気がして不思議。
OOな人の目的ってやっぱりプログラミング?
よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに
違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって
OODBを使いたがるとは限らないよ。
ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。
で、私は「永続化すべきデータに違いはない」とまるっきり区別しない事に、
違和感を感じていると書いたつもりです。
(この引用の仕方はU ◆CZtFsGiu0cさんの意図とは違っているかもしれません)
あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。
このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん
ですが。
>ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。
よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。
>あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。
これは、「インピーダンス・ミスマッチ」の一言につきると思います。
設計したモデルをデータストアの都合で崩さなければならない、ということに
不満がありますね。
それから細かいことを言うと、データストアがOODBでない場合はカプセル化を
破るか永続化するデータを持つクラスが永続化の手段を知っている必要がある
ので、それはあまり歓迎できないと言うのはあります。
>しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。
合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
壁があるからなんとかできないか、と考えるのは自然ではないですか?
> よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
> すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。
データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。
> 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
> 壁があるからなんとかできないか、と考えるのは自然ではないですか?
プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。
「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。
>データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。
うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
当たり前だと思うけど、具体的にはどういうことですか?
>プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。
「顧客との意思疎通」はともかく、保守・運用やアドホックなデータ検索に
関しては今のOODBはダメダメですよ。それに関する認識はここにもさんざん
書きました。だからこそ、ObjectCacheやCacheに期待するところがあるん
ですけどね。
>「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。
もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
ことしか考えてないってことないですか? プログラムの保守についてはどう
思ってますか? データベースはシステムの一部にしか過ぎないんですよ。
> うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
> 当たり前だと思うけど、具体的にはどういうことですか?
で書いたようなことです。
「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。
> もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
> ことしか考えてないってことないですか? プログラムの保守についてはどう
> 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。
保守では有りませんが、DBMSの販売に昔かかわっていた者です。
DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。
・1つのDBに複数のプログラムがアクセスする場合が非常に多いこと
・システムの稼動に従ってデータ資産が増えていくが、その構造は簡単には変えられないこと
・CPUの速度よりもディスクの速度の方が圧倒的に遅いこと
プログラムだってシステムの一部に過ぎません。しかし「『一部』同士だから
検討の優先順位は同等だ」ということにはならないでしょう。
(無論個別の事情によってはいろいろと程度が変わってくると思いますが)
以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと
思います。
>「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。
そういうことですか。実装上必要な揮発性のデータを永続化するなんて
ありえない、というか「データと手続きが不可分」と言う言葉を曲解してる
ように思います。
>DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。
特に反対することはないんですが、やはり誤解されていると思います。
OOでやってもエンティティはフローズンスポットになるのでそんなに
変更は入りませんし、既存のシステムは当然考慮しますよ。
なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・
まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・
なんかオレ様の知らないうちにオブジェクトDBシステム用の
クエリ言語が標準化されてますた(・へ・)
ttp://www.odmg.org/ 日本語の情報元知ってるひといたらキボンヌ
この辺も
「LDP」
ttp://lambda.uta.edu/lambda-DB/manual/ 「出世魚」
ttp://www.db.is.kyushu-u.ac.jp/fish/expl/summary.html あとFastDB試してみたらなかなか使いやすかった。
でも誰も使ってない予感
今現在はどの組み合わせのシステムがベストなの？
業務処理するには何がベスト？
注文番号
注文先
商品
単価
個数
消費税額
みたいなオブジェクトだとして。RDBMS だと、注文先番号 や 商品番号で
マスタとリレーションするよね。
O/R マッピングだと、マスタとジョインした結果を格納する、ってことができて、
RDBMS におけるメリット（マスタに変更があった場合、オブジェクトにもその
変更が反映できる）を受けられる。
OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに
変更があったらどうするんだろう？
注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト
するってこと？
注文番号
注文先キー
商品キー
単価
個数
消費税額
って感じ？ これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。
具体的にいうとリファレンスって何を保持するの？
public class Order {
int OrderNo;
Comany OrderCompany;
Product OrderProduct;
BigDecimal UnitPrice;
int Quantity;
BigDecimal Tax;
}
ってのを当初考えてたんだけど、これじゃ駄目だよね？
使ったことねえものわがらん。
とするよね、永続化されてる Order クラスには、それがわからないと
思うのですよ。
と思ったんだけど、永続化されるのはあくまで Product クラスの参照であって、
Product クラスの変更は自動的に Order クラスにも伝播するってことかな？
XML への永続化とかだと、そうはならないんで、すっかり誤解してました。
実装によって細部は異なると思うけど基本的には
productオブジェクトもorderオブジェクトも、
どちらも永続化されていて、永続化されたDBの中で参照関係が
保持されていると考えるのが普通じゃないかと。
それはヤバイ。製品仕様が変更になって、商品名が変わったときに、
以前に受けた注文の商品名が変わってしまうと、商売上、会計上
無茶苦茶になる。
業務知識に依存で、参照を持つ方法も取れるし、オブジェクト自体を持つ
事も出来るし、必要な項目だけコピーする事も出来る。
どれを選ぶかは、業務次第。
実はまともに触ったことないけど、
届いたらじっくり読んで遊んでみることにするよ。
英語苦手だけど。
「どうやって直しゃいいーの？やりようねーよ。」って・・・hahaha
でもって塩漬け
ttp://wiki.ninki.org/wiki.cgi?p=OODB+%2d+%a5%aa%a5%d6%a5%b8%a5%a7%a5%af%a5%c8%bb%d8%b8%fe%a5%c7%a1%bc%a5%bf%a5%d9%a1%bc%a5%b9 すまん
Javaのやつを探していたのでスルーしてた
コンパイル時にチェックできてもポータビリティがないじゃないか
仕事でも趣味でも使ってる人います？
趣味で弄ろうとしてて苦戦中。
Javaで書いてるんだけどオブジェクトをsaveしたりopenしたりする専用のDAOクラス作った方がいいのかな？
本格的なプログラムの場合はDAO作った方がいいよ。
海外だと弄ってる人多そうだけど、日本は少ないね。
たしかリコーと提携して何かやるとかって話があったけど、
どうなったんだろう。
中国が積極的みたいだけど日本はね…
リコーは開発案件で積極的に導入してるぐらいだと思うけど。
しかしよくエンタープライズで使う気になるよなぁ
日本語の開発者向けフォーラムもさっぱりだし。
リコーはエンプラじゃなくて組み込みじゃないかな？
そうそう、サンプルが少ないから未だにDAOからオブジェクト追加出来ない俺…orz
組み込みなんだ？
自社製品になら納得。
サンプルってpdf読んだ？pdf＋あっちのフォーラムで解決出来るよ。
Dao作ってる人はQBE?NQ?SODA?どれベースにした？
ソートとか考えるとSODAしかないのかな・・・
でもSODA併用にすると思う
NQを完全に捨てた場合は、離れたくなる気持ちも解る…
実はQBEが一番好みなんだが、単純なクエリにしか使えない
全部のエンジン対応のBaseクラス実装してみた。
・・・Update、Deleteがスマートになった位。
>実はQBEが一番好みなんだが、単純なクエリにしか使えない
QBEは完全におまけだね、用意した意味がわからないレベル。
NQ→SODAも怪しい所があるらしいし。
・・・やっぱりH2＋O/Rでいいやｗ
Object Store Personal Edition で時代を切り開こうとしてたJava厨涙目ｗｗｗ
OODBならGBのファイル管理も余裕ですよ！と謳っているけど何で？
DVDから直抜きしたエロ動画コレクションをOODBで管理すると仮定して
神イグザンプルを教えてエロイ人！！！
RDBじゃ無理とか言ってなければ別に嘘じゃない。
ttp://japan.internet.com/linuxtoday/20081208/5.html 現に使われてるだろ
とっととOODBをもっと広めろやアホども。
じゃねーよ。
しっかり広めろ。
メッセージを送ってメソッドを呼び出せないなら
オブジェクト指向型じゃない。
だからSQLiteのような手軽なOODBが無いかと言ってんの。
OK？
無いからお引き取りください。
ttp://goo.gl/ogJo8a ttp://www.doraibu.com/ どらいぶ帳よろしく ttps://goo.gl/q9Ml0S これは嘘でしょ？本当だったら落ち込むわ。。
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
66CFHAV81O
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
