O-Rマッピングかよ！
語りやがれ！
想像のとおりで、このアイデアには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
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
