OODB - オブジェクト指向データベース
>>100
> ３）業務に変更があった場合、修正箇所を最小限にする。
> なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
で展開してた議論だと思います。
> ３）業務に変更があった場合、修正箇所を最小限にする。
> なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
で展開してた議論だと思います。
|
|
|
102 ：NAME IS NULL：04/07/25 21:40 ID:???
>>101
> 過去のプログラムの実行結
> 果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
> で展開してた議論だと思います。
そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
> それはプログラミングの場合は確立されてるけど、
だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
#現実的にはRDBしか選択肢がないに等しいんだけどね。
> 過去のプログラムの実行結
> 果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
> で展開してた議論だと思います。
そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
> それはプログラミングの場合は確立されてるけど、
だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
#現実的にはRDBしか選択肢がないに等しいんだけどね。
103 ：NAME IS NULL：04/07/25 23:45 ID:???
>>102
> そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの？」と
いうのが話（やそもそものスレ）の発端でしょ？
> だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。
上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
システム開発ってプログラミング関連だけじゃなくて方式設計とか、ネットワー
ク設計とか、ソフトウェア構成とか、いろんな要素が絡んでると思うんだけど。
その時に「DBMS」と呼ばれる構成要素に対して求められる機能を考えたときに、
RDBやOODBはどんな特徴として位置づけられるんだろう、と考えるのが重要だ
と思います。
> そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの？」と
いうのが話（やそもそものスレ）の発端でしょ？
> だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。
上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
システム開発ってプログラミング関連だけじゃなくて方式設計とか、ネットワー
ク設計とか、ソフトウェア構成とか、いろんな要素が絡んでると思うんだけど。
その時に「DBMS」と呼ばれる構成要素に対して求められる機能を考えたときに、
RDBやOODBはどんな特徴として位置づけられるんだろう、と考えるのが重要だ
と思います。
104 ：NAME IS NULL：04/07/26 14:10 ID:???
>>95
> 研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。
OODB出始めは本当にアカデミック方面しか資料が無かったし。
でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、
> えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。
カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。
企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。
データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。
> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。
> 経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、
水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
＃極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。
> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?
システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
＃制御系の話はよく分からないんでパス。
> 不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
> ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。
相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
> 研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。
OODB出始めは本当にアカデミック方面しか資料が無かったし。
でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、
> えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。
カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。
企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。
データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。
> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。
> 経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、
水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
＃極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。
> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?
システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
＃制御系の話はよく分からないんでパス。
> 不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
> ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。
相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
105 ：NAME IS NULL：04/07/26 14:24 ID:???
>>96
> だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
> オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
オブジェクト指向以外の言語において、プログラミングの便宜のためにレコー
ドの概念が導入されたとは思えません。それは言語の問題の外からの要求に応
えたものだと思います。そしてその関係はオブジェクト指向言語でも変わるべ
きではないと思います。（というか変わる理由が分からない）
> すいません。MDAって何ですか？
Model Driven Architecture(だったかな?)。標準的なオブジェクト指向の道具
立てがそろってきたから、ここらでもう1回CASEの夢を見ようという動きだと、
私は理解をしています。
> ビジネスの世界ではコストより時間が優先されがちです。
> 時間＝コストと考えれば、コストですね。
すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
沢山出て来そう)ということでしょうか。
＃新規の話じゃないですよね。
まあ実際は資産を除却するよりも、追加で出来るならそっちの方が良いという
判断かもしれませんが。
> だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
> オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
オブジェクト指向以外の言語において、プログラミングの便宜のためにレコー
ドの概念が導入されたとは思えません。それは言語の問題の外からの要求に応
えたものだと思います。そしてその関係はオブジェクト指向言語でも変わるべ
きではないと思います。（というか変わる理由が分からない）
> すいません。MDAって何ですか？
Model Driven Architecture(だったかな?)。標準的なオブジェクト指向の道具
立てがそろってきたから、ここらでもう1回CASEの夢を見ようという動きだと、
私は理解をしています。
> ビジネスの世界ではコストより時間が優先されがちです。
> 時間＝コストと考えれば、コストですね。
すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
沢山出て来そう)ということでしょうか。
＃新規の話じゃないですよね。
まあ実際は資産を除却するよりも、追加で出来るならそっちの方が良いという
判断かもしれませんが。
106 ：NAME IS NULL：04/07/26 20:16 ID:???
>>103
>それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。
DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
それとも相互に影響を与えながら進化していっているのでしょうか？
>>研究者とくるとは、、、
それとも学生か学者かと。
>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理
別に揚げ足じゃないですが、判を押した請求書をつくらないところもありますよ。入金チェックは自動でしているところもあるでしょう。
人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
>便利な手段があるからといって、目的と混同すべきではないです。
便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
手段や目的とはその上で語られる別次元のものです。
>パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
>チして、サーバのディスクからページを転送してくるらしいです。
面白そうですね。OSいらんやんって思いました。
OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
>それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。
DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
それとも相互に影響を与えながら進化していっているのでしょうか？
>>研究者とくるとは、、、
それとも学生か学者かと。
>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理
別に揚げ足じゃないですが、判を押した請求書をつくらないところもありますよ。入金チェックは自動でしているところもあるでしょう。
人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
>便利な手段があるからといって、目的と混同すべきではないです。
便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
手段や目的とはその上で語られる別次元のものです。
>パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
>チして、サーバのディスクからページを転送してくるらしいです。
面白そうですね。OSいらんやんって思いました。
OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
107 ：NAME IS NULL：04/07/26 20:31 ID:???
>相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。
>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
これはOODBの場合って話ですか？ なぜでしょう？
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
>Model Driven Architecture(だったかな?)。
JavaWorldの５月号に特集を見つけました。今度読んでみます。
>> ビジネスの世界ではコストより時間が優先されがちです。
>> 時間＝コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。
いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし５ヶ月かかる。
・今のをむりやりにでも動くように修正すれば１ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、４ヶ月の時間差（＝コスト）がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に４ヶ月分だけの価値（＝利益）があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。
C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。
>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
これはOODBの場合って話ですか？ なぜでしょう？
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
>Model Driven Architecture(だったかな?)。
JavaWorldの５月号に特集を見つけました。今度読んでみます。
>> ビジネスの世界ではコストより時間が優先されがちです。
>> 時間＝コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。
いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし５ヶ月かかる。
・今のをむりやりにでも動くように修正すれば１ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、４ヶ月の時間差（＝コスト）がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に４ヶ月分だけの価値（＝利益）があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。
108 ：U ◆CZtFsGiu0c ：04/07/26 21:08 ID:???
なんか盛り上がってますね。現役のObjectStore使いです。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
>>88
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
＃ただし私が関わっているシステムはそのどちらでもありません
>>90
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
悲惨です。クライアントのキャッシュが肥大してメモリ不足になってしまう
なんてこともあります。
OODBが通常の業務システムに使われないのは、まず技術者が不足している
こと、ベンダのサポートが不安なこと(今はわかりませんが、昔はひどい
もんでした)、それとなにより業務システムにありがちなアドホックなデータ
操作(参照系、更新系含む)が難しいことでしょうか。なにかあるたびに
プログラムを一本作らなければならないのでは、運用が困難です。
ただ、個人的にはOODB(っていうかObjectStore)のキャッシュが使えたらな
、と思うことはよくあります。どんなデータかというと、
・参照は頻繁にされる。また、参照のコストが高い
・更新の頻度は少ないが、更新は即時に反映される必要がある
ようなものです。例えばリソースに対するアクセス制御データとかですね。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
>>88
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
＃ただし私が関わっているシステムはそのどちらでもありません
>>90
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
悲惨です。クライアントのキャッシュが肥大してメモリ不足になってしまう
なんてこともあります。
OODBが通常の業務システムに使われないのは、まず技術者が不足している
こと、ベンダのサポートが不安なこと(今はわかりませんが、昔はひどい
もんでした)、それとなにより業務システムにありがちなアドホックなデータ
操作(参照系、更新系含む)が難しいことでしょうか。なにかあるたびに
プログラムを一本作らなければならないのでは、運用が困難です。
ただ、個人的にはOODB(っていうかObjectStore)のキャッシュが使えたらな
、と思うことはよくあります。どんなデータかというと、
・参照は頻繁にされる。また、参照のコストが高い
・更新の頻度は少ないが、更新は即時に反映される必要がある
ようなものです。例えばリソースに対するアクセス制御データとかですね。
109 ：NAME IS NULL：04/07/27 00:40 ID:f4b3F8Gz
非常に面白いスレですね。OODB未経験ですが割り込ませてください。
（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
（最終的にはCORBA/CCMまで絡ませたい）
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること（ユーザインターフェイスを含む）」なのです。
（以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。）
ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
（MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう）。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ（例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール）が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか？
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
（ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします）
（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
（最終的にはCORBA/CCMまで絡ませたい）
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること（ユーザインターフェイスを含む）」なのです。
（以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。）
ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
（MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう）。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ（例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール）が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか？
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
（ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします）
110 ：NAME IS NULL：04/07/27 00:42 ID:f4b3F8Gz
続き。
あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
まずは上級エンジニアが触ってみて遊んでみて「いいな、コレ」って思ってもらわなければ、いつまでたっても一部のコアな開発者のマニアックな玩具に留まってしまう気がします。
それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応（←これ重要！2バイト対応されていない製品はユーザに嫌われる）
といったようなものがサクっと出てくるようでないと・・・。
（フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・？）
あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
まずは上級エンジニアが触ってみて遊んでみて「いいな、コレ」って思ってもらわなければ、いつまでたっても一部のコアな開発者のマニアックな玩具に留まってしまう気がします。
それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応（←これ重要！2バイト対応されていない製品はユーザに嫌われる）
といったようなものがサクっと出てくるようでないと・・・。
（フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・？）
111 ：U ◆CZtFsGiu0c ：04/07/27 12:35 ID:???
>>109
>（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
お久しぶりです。
＃と言ってもどなたかわかりませんが:-)
>今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
ObjectStore以外のOODB製品はよく知らないのですが、最近Cacheという
製品が気になっています。これが謳い文句どおりの製品ならかなりのもの
ではないかと思うのですが、ちょっと眉に唾をつけてます。暇があれば、
試用版を使ってみたいと思うのですが。
>あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
XMLDBなら、Apache Xindiceはかなり簡単です。私はダウンロードして5分で
とりあえず使えるようになりました。
>（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
お久しぶりです。
＃と言ってもどなたかわかりませんが:-)
>今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
ObjectStore以外のOODB製品はよく知らないのですが、最近Cacheという
製品が気になっています。これが謳い文句どおりの製品ならかなりのもの
ではないかと思うのですが、ちょっと眉に唾をつけてます。暇があれば、
試用版を使ってみたいと思うのですが。
>あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
XMLDBなら、Apache Xindiceはかなり簡単です。私はダウンロードして5分で
とりあえず使えるようになりました。
112 ：NAME IS NULL：04/07/27 16:04 ID:???
>>106
> DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
> それとも相互に影響を与えながら進化していっているのでしょうか？
もちろん相互に影響を与えているでしょう。
> それとも学生か学者かと。
ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
なんでしょうか?
> 人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
> それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
> 便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
> 手段や目的とはその上で語られる別次元のものです。
アパートを借りる人や都市計画を考える人にとっては水道管はあって当然です。
あって当然ですが、断水してるとか、そもそも水源から繋がってなかったら話になりません。
この例ではITという便利な手段を「構築する人にとって」どう捕らえるべきかという話でしょ?
> 面白そうですね。OSいらんやんって思いました。
> OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
OS組み込みのモジュールならば面白いかもしれませんがOSを置き換えたり、単
独で立ち上げて外部に公開するもんじゃないと思います。
NW・CD-ROM・マウス・キーボードドライバも用意して、コンテキストスイッチ
機能も入れてDBマシンとしてハードウェアごと用意するのは有りかもしれませ
ん。(使いにくそうだけど)
> DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
> それとも相互に影響を与えながら進化していっているのでしょうか？
もちろん相互に影響を与えているでしょう。
> それとも学生か学者かと。
ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
なんでしょうか?
> 人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
> それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
> 便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
> 手段や目的とはその上で語られる別次元のものです。
アパートを借りる人や都市計画を考える人にとっては水道管はあって当然です。
あって当然ですが、断水してるとか、そもそも水源から繋がってなかったら話になりません。
この例ではITという便利な手段を「構築する人にとって」どう捕らえるべきかという話でしょ?
> 面白そうですね。OSいらんやんって思いました。
> OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
OS組み込みのモジュールならば面白いかもしれませんがOSを置き換えたり、単
独で立ち上げて外部に公開するもんじゃないと思います。
NW・CD-ROM・マウス・キーボードドライバも用意して、コンテキストスイッチ
機能も入れてDBマシンとしてハードウェアごと用意するのは有りかもしれませ
ん。(使いにくそうだけど)
113 ：NAME IS NULL：04/07/27 16:41 ID:???
>>107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。
> 外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。
開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
> これはOODBの場合って話ですか？ なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
いくつか考えられますが。
１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。
最初に作った人はハッピーなんでしょうけど。
いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。
２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか？
システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。
３：基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。
思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。
> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。
＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。
> 外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。
開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
> これはOODBの場合って話ですか？ なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
いくつか考えられますが。
１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。
最初に作った人はハッピーなんでしょうけど。
いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。
２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか？
システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。
３：基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。
思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。
> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。
＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。
114 ：NAME IS NULL：04/07/27 16:54 ID:???
>>108
> OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
> ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
> につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
> あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
> 悲惨です。
買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
> ・参照は頻繁にされる。また、参照のコストが高い
> ・更新の頻度は少ないが、更新は即時に反映される必要がある
>
> ようなものです。例えばリソースに対するアクセス制御データとかですね。
この利用例のアーキテクチャはどうなっているでしょうか。個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
> OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
> ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
> につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
> あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
> 悲惨です。
買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
> ・参照は頻繁にされる。また、参照のコストが高い
> ・更新の頻度は少ないが、更新は即時に反映される必要がある
>
> ようなものです。例えばリソースに対するアクセス制御データとかですね。
この利用例のアーキテクチャはどうなっているでしょうか。個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
115 ：U ◆CZtFsGiu0c ：04/07/27 19:23 ID:???
>>113
>１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。
>２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。
これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
高いと思います。
>>114
>CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
間で同一データを扱っている際に、更新を即時に反映できることです。
通信系システムで採用されている理由も同じでしょうね。
＃もう一つ共通点としては「データの再利用」や「アドホックな操作」が
＃不要なことも挙げられます
>買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
とプログラムが異常終了します:-P
>この利用例のアーキテクチャはどうなっているでしょうか。
まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
すいません、つながりがよくわかりません。
>１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。
>２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。
これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
高いと思います。
>>114
>CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。
一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
間で同一データを扱っている際に、更新を即時に反映できることです。
通信系システムで採用されている理由も同じでしょうね。
＃もう一つ共通点としては「データの再利用」や「アドホックな操作」が
＃不要なことも挙げられます
>買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。
ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
とプログラムが異常終了します:-P
>この利用例のアーキテクチャはどうなっているでしょうか。
まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。
すいません、つながりがよくわかりません。
116 ：NAME IS NULL：04/07/27 19:56 ID:???
>>115
> できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
> 高いと思います。
個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
ログをXML形式で溜めていくのはありそうですけど。
＃インデキシングやトランザクション・排他制御管理がどうなっているのかはぜ
＃んぜん追っかけてません。
> 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
> 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
> 間で同一データを扱っている際に、更新を即時に反映できることです。
部品管理システムと連動したアプリケーション、というイメージでしょうか。
> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
いいえ、上で書いた知識でほぼすべてです(笑)。
> すいません、つながりがよくわかりません。
アクセスするアプリケーションが固定で、そのアプリケーションを捨て去ると
きにはDBも破棄してしまうとか。「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
業務系・情報系のようにDBを置いておいてあちこちからアクセスされるのを待っ
ているという形態ではないと。
そして、ObjectStoreの「仮想メモリをそのまま云々」というのはそうした
（制御系?組み込み系?）の方が向いてるんじゃないかと想像しています。だか
ら私はObjectStoreは好きになれそうも無いけど、PSEはなんとなく良い印象を
持っています。
＃全部想像ですけど。
> できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
> 高いと思います。
個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
ログをXML形式で溜めていくのはありそうですけど。
＃インデキシングやトランザクション・排他制御管理がどうなっているのかはぜ
＃んぜん追っかけてません。
> 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
> 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
> 間で同一データを扱っている際に、更新を即時に反映できることです。
部品管理システムと連動したアプリケーション、というイメージでしょうか。
> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
いいえ、上で書いた知識でほぼすべてです(笑)。
> すいません、つながりがよくわかりません。
アクセスするアプリケーションが固定で、そのアプリケーションを捨て去ると
きにはDBも破棄してしまうとか。「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
業務系・情報系のようにDBを置いておいてあちこちからアクセスされるのを待っ
ているという形態ではないと。
そして、ObjectStoreの「仮想メモリをそのまま云々」というのはそうした
（制御系?組み込み系?）の方が向いてるんじゃないかと想像しています。だか
ら私はObjectStoreは好きになれそうも無いけど、PSEはなんとなく良い印象を
持っています。
＃全部想像ですけど。
117 ：NAME IS NULL：04/07/28 22:13 ID:???
>>112
> ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
> てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
> ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
> なんでしょうか?
さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
他意はありません。
＃２ｃｈでまじめに議論できるとはめずらしいスレですね。パソ通みたいで懐かしいです。
> ｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
> 能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
> 署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
下す必要があるときだけ、ユーザに伝えればいいと考えます。
> ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
> てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
> ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
> なんでしょうか?
さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
他意はありません。
＃２ｃｈでまじめに議論できるとはめずらしいスレですね。パソ通みたいで懐かしいです。
> ｢確認｣も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
> 能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
> 署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。
業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
下す必要があるときだけ、ユーザに伝えればいいと考えます。
118 ：NAME IS NULL：04/07/28 22:19 ID:???
>>113
> まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
> 象は違わないし、保存する必要性も変わらないと思います。
では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
>> esql/c でもpro*cでもいいですが、プリプロセッサです。
>
>開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
組込型言語とでもいうんですかね。忘れました。
開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
それからコンパイルされ、普通の実行形式のプログラムに変換されます。
> まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
> 象は違わないし、保存する必要性も変わらないと思います。
では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
>> esql/c でもpro*cでもいいですが、プリプロセッサです。
>
>開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
組込型言語とでもいうんですかね。忘れました。
開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
それからコンパイルされ、普通の実行形式のプログラムに変換されます。
119 ：U ◆CZtFsGiu0c ：04/07/29 12:25 ID:???
>>116
>個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
ほうが扱いやすいです。
>部品管理システムと連動したアプリケーション、というイメージでしょうか。
そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
という仕組みに使われているはずです。
>> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>いいえ、上で書いた知識でほぼすべてです(笑)。
各クライアントがメモリ上にキャッシュを持っており、キャッシュ内のオブジェクト
を更新すると、その更新が他のクライアントのキャッシュにも反映される、という
ことでおわかりになるでしょうか。
>「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
たとえば、NTドメインのユーザ/グループ情報と、ファイルに対するアクセス権
の設定をマッチさせて、現在のセッションのユーザが指定されたファイルに対して
指定されたアクションが実行可能かを判別する、といった感じでイメージして
いただけるでしょうか。
>個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
ほうが扱いやすいです。
>部品管理システムと連動したアプリケーション、というイメージでしょうか。
そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
という仕組みに使われているはずです。
>> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>いいえ、上で書いた知識でほぼすべてです(笑)。
各クライアントがメモリ上にキャッシュを持っており、キャッシュ内のオブジェクト
を更新すると、その更新が他のクライアントのキャッシュにも反映される、という
ことでおわかりになるでしょうか。
>「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
たとえば、NTドメインのユーザ/グループ情報と、ファイルに対するアクセス権
の設定をマッチさせて、現在のセッションのユーザが指定されたファイルに対して
指定されたアクションが実行可能かを判別する、といった感じでイメージして
いただけるでしょうか。
120 ：U ◆CZtFsGiu0c ：04/07/29 12:26 ID:???
121 ：NAME IS NULL：04/07/29 13:19 ID:???
>>117
> さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
確かにプログラマではありません。人の作ったソースの一部を性能チューニン
グのために見たりいじったりしたことはありますが。
システム開発の時にはプログラミング以外にもいろんな技術要因が絡んできま
すよ。
> 研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
業界に何年かいれば、誰でもある程度のシステム観とかポリシーみたいなもの
は出来てくるんじゃないでしょうか。
> 業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
> 自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
> 下す必要があるときだけ、ユーザに伝えればいいと考えます。
この場合例に出していたのは経理の入出金ですからチェックしなきゃいけない
でしょう。月次締めなどを経理の人が必死でやってませんか?そもそもどの請
求書に対応した入金かどうかなんて、十分な情報がある保証は無いですし。
業務上運用手抜きしてノーチェックにしてしまう可能性はありますが。少なく
ともいつでも確認できる状態にしておかないと、システムにバグがあったとき
に対処できないし、会計監査も危ないんじゃないでしょうか。
監視ツールがログを監視して警告を出す、というような場合は通常は無視して
しまって、問題が起こったときに「ここまでは正常だった」ということが分か
れば良いと思います。
> さあ？ 何となく、プログラマではないなと思いまして。私はプログラマですが。
確かにプログラマではありません。人の作ったソースの一部を性能チューニン
グのために見たりいじったりしたことはありますが。
システム開発の時にはプログラミング以外にもいろんな技術要因が絡んできま
すよ。
> 研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
業界に何年かいれば、誰でもある程度のシステム観とかポリシーみたいなもの
は出来てくるんじゃないでしょうか。
> 業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
> 自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
> 下す必要があるときだけ、ユーザに伝えればいいと考えます。
この場合例に出していたのは経理の入出金ですからチェックしなきゃいけない
でしょう。月次締めなどを経理の人が必死でやってませんか?そもそもどの請
求書に対応した入金かどうかなんて、十分な情報がある保証は無いですし。
業務上運用手抜きしてノーチェックにしてしまう可能性はありますが。少なく
ともいつでも確認できる状態にしておかないと、システムにバグがあったとき
に対処できないし、会計監査も危ないんじゃないでしょうか。
監視ツールがログを監視して警告を出す、というような場合は通常は無視して
しまって、問題が起こったときに「ここまでは正常だった」ということが分か
れば良いと思います。
122 ：NAME IS NULL：04/07/29 13:41 ID:???
>>118
> では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。
＃そしてその要求は言語から来るものではありません。
後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
たもんじゃないということは更に上でも書いてます)
> 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
> それからコンパイルされ、普通の実行形式のプログラムに変換されます。
それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
でしょ?
SQLをコードの中に埋め込んだということは、
・その部分が実行されるときはネットワークを介してサーバへリクエストが飛ぶ
・サーバ内で何かが実行される
・その結果が自分のコードの中へ返ってくる
ということがまず考えられて、さらに
・そのサーバへは別のプログラムもリクエストを出している
・今のプロジェクトで開発したプログラムじゃなくて、例えばAccessを使った管理ツールもリクエストを飛ばしている
というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
ち当たると思うんですが。
例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
・HTTPサーバをJavaで作った
・WebブラウザもJavaで作った
とここまでは良いとして、
・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
なんて考えないでしょ?
> では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。
＃そしてその要求は言語から来るものではありません。
後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
たもんじゃないということは更に上でも書いてます)
> 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
> それからコンパイルされ、普通の実行形式のプログラムに変換されます。
それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
でしょ?
SQLをコードの中に埋め込んだということは、
・その部分が実行されるときはネットワークを介してサーバへリクエストが飛ぶ
・サーバ内で何かが実行される
・その結果が自分のコードの中へ返ってくる
ということがまず考えられて、さらに
・そのサーバへは別のプログラムもリクエストを出している
・今のプロジェクトで開発したプログラムじゃなくて、例えばAccessを使った管理ツールもリクエストを飛ばしている
というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
ち当たると思うんですが。
例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
・HTTPサーバをJavaで作った
・WebブラウザもJavaで作った
とここまでは良いとして、
・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
なんて考えないでしょ?
123 ：NAME IS NULL：04/07/29 14:10 ID:???
>>119
> 複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
> ほうが扱いやすいです。
XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
・referenceは結局ID属性を使いまくりになる。
・そのときの排他制御がどうなるのかいまひとつ分からない。
・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
というあたりが不安視するところです。
> そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
> 即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
> 状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
> という仕組みに使われているはずです。
なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
＃competitorはRDBじゃなくてCORBA。
ObjectStore限定の性質なのか、OODBに共通して見られる特徴なのかは分かり
ませんが、確かにそれは便利そうです。RDBで無理にやろうとしたら定期的に
リクエストを投げてpollingしなきゃいけないところです。
やはりOODBは組み込み向け（機器組み込みじゃなくてアプリケーション組み込
み）に向いている感じがします。
だとするとベンダの営業文句は根本的にはずしてる気がする。今はどうか知り
ませんが、かつては「次世代の企業内基幹システムはオブジェクト指向開発が
広まってOODBだ!」っていう風じゃなかったでしたっけ?
> 複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
> ほうが扱いやすいです。
XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
・referenceは結局ID属性を使いまくりになる。
・そのときの排他制御がどうなるのかいまひとつ分からない。
・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
というあたりが不安視するところです。
> そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
> 即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
> 状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
> という仕組みに使われているはずです。
なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
＃competitorはRDBじゃなくてCORBA。
ObjectStore限定の性質なのか、OODBに共通して見られる特徴なのかは分かり
ませんが、確かにそれは便利そうです。RDBで無理にやろうとしたら定期的に
リクエストを投げてpollingしなきゃいけないところです。
やはりOODBは組み込み向け（機器組み込みじゃなくてアプリケーション組み込
み）に向いている感じがします。
だとするとベンダの営業文句は根本的にはずしてる気がする。今はどうか知り
ませんが、かつては「次世代の企業内基幹システムはオブジェクト指向開発が
広まってOODBだ!」っていう風じゃなかったでしたっけ?
124 ：NAME IS NULL：04/07/29 14:35 ID:???
>>115
> ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
> とプログラムが異常終了します:-P
これ、スルーしようか迷ったけどどうしても気になって。
さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
たぶんPage fault利用のアーキテクチャに起因するもので、10年以上バグでは
無く仕様と主張しているんじゃないでしょうか。(推測)
＝＝＝以下、推測が合っているとして＝＝＝
普通製品でこんなことが起こったら致命的な障害としてベンダが認識して、ど
こかのバージョンアップ時に修正されるはずだと思います。
修正不可能だったら販売中止にすべきだし、R&D時に「原理的に修正不可能」
と判明したのだったら製品販売ビジネスをあきらめるはずです。その代わりに
開発請負ビジネスに変更して自社内利用に留めておくとか。
変なドライバを入れたらOSが落ちまくるので苦情の電話を入れたら「仕様です。
マウスはあまり激しく動かさないでください」と言われ、しかもそのままの品
質で10年以上も販売し続けているようなものだと思います。
「作ってたら何か出来ちゃった。出来ちゃったから売っちゃおう。動かしてど
うなるかは知らないけど。」と考え続けているように見えます。
技術的にも営業的にも、モラルに問題があるとしか思えません。
> ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
> とプログラムが異常終了します:-P
これ、スルーしようか迷ったけどどうしても気になって。
さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
たぶんPage fault利用のアーキテクチャに起因するもので、10年以上バグでは
無く仕様と主張しているんじゃないでしょうか。(推測)
＝＝＝以下、推測が合っているとして＝＝＝
普通製品でこんなことが起こったら致命的な障害としてベンダが認識して、ど
こかのバージョンアップ時に修正されるはずだと思います。
修正不可能だったら販売中止にすべきだし、R&D時に「原理的に修正不可能」
と判明したのだったら製品販売ビジネスをあきらめるはずです。その代わりに
開発請負ビジネスに変更して自社内利用に留めておくとか。
変なドライバを入れたらOSが落ちまくるので苦情の電話を入れたら「仕様です。
マウスはあまり激しく動かさないでください」と言われ、しかもそのままの品
質で10年以上も販売し続けているようなものだと思います。
「作ってたら何か出来ちゃった。出来ちゃったから売っちゃおう。動かしてど
うなるかは知らないけど。」と考え続けているように見えます。
技術的にも営業的にも、モラルに問題があるとしか思えません。
125 ：U ◆CZtFsGiu0c ：04/07/29 17:32 ID:???
>>124
>さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
クライアントの話です。ただし、誤解のないように言っておくとメモリ
不足を捕捉して安全に終了するようにはできると思います。ただし、
どちらにしてもアプリケーションの続行は不可能なので、問題は問題
ですね。
…とここまで書いて、本当に合っているのか不安になったのですが、
ここでフォローしてもらうのは無理かな。
ああ、そういえばObjectStore付属のツールであるInspectorは、かなり
あっさり落ちます:-P
>さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。
クライアントの話です。ただし、誤解のないように言っておくとメモリ
不足を捕捉して安全に終了するようにはできると思います。ただし、
どちらにしてもアプリケーションの続行は不可能なので、問題は問題
ですね。
…とここまで書いて、本当に合っているのか不安になったのですが、
ここでフォローしてもらうのは無理かな。
ああ、そういえばObjectStore付属のツールであるInspectorは、かなり
あっさり落ちます:-P
126 ：NAME IS NULL：04/07/29 20:06 ID:???
>>125
> クライアントの話です。ただし、誤解のないように言っておくとメモリ
> 不足を捕捉して安全に終了するようにはできると思います。
SIGSEGVをキャッチしたり、定期的にsbrkで調べたりとかでしょうか。自分が
作ろうとした機能のためにやるんならともかく、買ってきた製品のためにやる
必要があるんだったら相当使いづらいですね。
ドライバを作る繊細さで業務アプリを構築するような。明らかに一般公開する
レイヤを間違えている気がする。
Java版もあったと思うんですが、同じことは出来るのかな。
どっちにしろ業務中断になるけど。
> クライアントの話です。ただし、誤解のないように言っておくとメモリ
> 不足を捕捉して安全に終了するようにはできると思います。
SIGSEGVをキャッチしたり、定期的にsbrkで調べたりとかでしょうか。自分が
作ろうとした機能のためにやるんならともかく、買ってきた製品のためにやる
必要があるんだったら相当使いづらいですね。
ドライバを作る繊細さで業務アプリを構築するような。明らかに一般公開する
レイヤを間違えている気がする。
Java版もあったと思うんですが、同じことは出来るのかな。
どっちにしろ業務中断になるけど。
127 ：NAME IS NULL：04/07/29 20:37 ID:???
>>122
> 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
> うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
> たもんじゃないということは更に上でも書いてます)
では何だったらいいのでしょうか？
> それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
> パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
> でしょ?
聞かれたから答えたのに。ｼｸｼｸ
> というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
> ち当たると思うんですが。
（１について）
別にRDBでもOODBでも同じ問題だと思います。
（２について）
確かにそうですね。
（３について）
そうは思わないです。ただのいちゃもんに聞こえます。
>・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
>なんて考えないでしょ?
言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
> 例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
> ・HTTPサーバをJavaで作った
> ・WebブラウザもJavaで作った
> とここまでは良いとして、
> ・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> なんて考えないでしょ?
> 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
> うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
> たもんじゃないということは更に上でも書いてます)
では何だったらいいのでしょうか？
> それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
> パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
> でしょ?
聞かれたから答えたのに。ｼｸｼｸ
> というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
> ち当たると思うんですが。
（１について）
別にRDBでもOODBでも同じ問題だと思います。
（２について）
確かにそうですね。
（３について）
そうは思わないです。ただのいちゃもんに聞こえます。
>・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
>なんて考えないでしょ?
言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
> 例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
> ・HTTPサーバをJavaで作った
> ・WebブラウザもJavaで作った
> とここまでは良いとして、
> ・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> なんて考えないでしょ?
128 ：NAME IS NULL：04/07/29 20:38 ID:???
129 ：NAME IS NULL：04/07/29 22:55 ID:???
>>127
> では何だったらいいのでしょうか？
それで今のところラッパーが世に出てきてるということでしょう。
将来もっと便利な解決策が出るかもしれませんが。
確認ですが、ここで展開されている議論はOODBを使うとか、言語オブジェクト
をそのままDBに入れる手法についてどう思うか、ということですよね。
「ラッパーで良い」、ということなら「そうですね」という答えになります。
少なくともObjectStoreの提供するアーキテクチャとか>>90で書かれた「イン
スタンスのまんま（オブジェクトのまんま）格納や抽出なんかができれば」と
いう状況は、理想とはほど遠いと主張しています。
> 聞かれたから答えたのに。ｼｸｼｸ
>>104では「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると
認識していたんだろう?」という質問をしています。
私の考えでは、「開発」の手法や便宜よりも「実行」の方が重要性が高いです。
＃もしかして「実行」と聞くと「コンパイル」をイメージしますか？
> （１について）
> 別にRDBでもOODBでも同じ問題だと思います。
最初に出来たオブジェクト指向設計・実装の成果が、たとえば５年間(償却す
る間)ぐらいはそのDBにアクセスするアプリケーション開発に強制的に利用で
きると考えて良いでしょうか？（開発環境はずっと同じと仮定）
分析あたりまではともかく、設計や実装は難しいんじゃないかという印象を持っ
ています。
私はアプリ実装の都合と関係のない設計の方が長持ちする可能性が高いと思い
ます。もちろんRDBにしたところで、いつの間にかフラグ情報が山のように入っ
てきて身動きがとれなくなってしまうことは良くあります。
変な情報が入りすぎてしまうと、きれいに作り直そうとも移行できなくなって
しまうでしょう。
> （３について）
> そうは思わないです。ただのいちゃもんに聞こえます。
これは私のプログラマ観（というか、オブジェクト指向屋観）なので、確かに
根拠や論理性がなかったです。_o_
> >・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> >なんて考えないでしょ?
>
> 言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
いいえ、HTMLとHTTPという言語とは関係のない便利なものがあるおかげで、い
ろんなブラウザから同じサーバにアクセスして同じ情報を閲覧できるようになっ
ている、ということです。
まぁ、表示が大幅に崩れたり、アプレットやスクリプトやフラッシュがどんど
ん入ってきて混乱した状況ですけど。
> では何だったらいいのでしょうか？
それで今のところラッパーが世に出てきてるということでしょう。
将来もっと便利な解決策が出るかもしれませんが。
確認ですが、ここで展開されている議論はOODBを使うとか、言語オブジェクト
をそのままDBに入れる手法についてどう思うか、ということですよね。
「ラッパーで良い」、ということなら「そうですね」という答えになります。
少なくともObjectStoreの提供するアーキテクチャとか>>90で書かれた「イン
スタンスのまんま（オブジェクトのまんま）格納や抽出なんかができれば」と
いう状況は、理想とはほど遠いと主張しています。
> 聞かれたから答えたのに。ｼｸｼｸ
>>104では「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると
認識していたんだろう?」という質問をしています。
私の考えでは、「開発」の手法や便宜よりも「実行」の方が重要性が高いです。
＃もしかして「実行」と聞くと「コンパイル」をイメージしますか？
> （１について）
> 別にRDBでもOODBでも同じ問題だと思います。
最初に出来たオブジェクト指向設計・実装の成果が、たとえば５年間(償却す
る間)ぐらいはそのDBにアクセスするアプリケーション開発に強制的に利用で
きると考えて良いでしょうか？（開発環境はずっと同じと仮定）
分析あたりまではともかく、設計や実装は難しいんじゃないかという印象を持っ
ています。
私はアプリ実装の都合と関係のない設計の方が長持ちする可能性が高いと思い
ます。もちろんRDBにしたところで、いつの間にかフラグ情報が山のように入っ
てきて身動きがとれなくなってしまうことは良くあります。
変な情報が入りすぎてしまうと、きれいに作り直そうとも移行できなくなって
しまうでしょう。
> （３について）
> そうは思わないです。ただのいちゃもんに聞こえます。
これは私のプログラマ観（というか、オブジェクト指向屋観）なので、確かに
根拠や論理性がなかったです。_o_
> >・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> >なんて考えないでしょ?
>
> 言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？
いいえ、HTMLとHTTPという言語とは関係のない便利なものがあるおかげで、い
ろんなブラウザから同じサーバにアクセスして同じ情報を閲覧できるようになっ
ている、ということです。
まぁ、表示が大幅に崩れたり、アプレットやスクリプトやフラッシュがどんど
ん入ってきて混乱した状況ですけど。
130 ：NAME IS NULL：04/07/29 23:21 ID:???
>>128
> ベンダの営業文句が根本的にはずして無かった事ありましたっけ？
「誇大妄想か？」と思うような表現はデフォルトですが、適用ジャンル・レイ
ヤを大幅にはずすことはそんなにないでしょう。
PhotoShopでVBスクリプトが使えるみたいですが、だからといってアドビが
「基幹システム開発に革命をもたらす！！」とか言ってSI市場に売り込み攻勢
をかけたら「アホか」と思うでしょ？
＃ODBCが使えるのかどうかは知らない。
> ベンダの営業文句が根本的にはずして無かった事ありましたっけ？
「誇大妄想か？」と思うような表現はデフォルトですが、適用ジャンル・レイ
ヤを大幅にはずすことはそんなにないでしょう。
PhotoShopでVBスクリプトが使えるみたいですが、だからといってアドビが
「基幹システム開発に革命をもたらす！！」とか言ってSI市場に売り込み攻勢
をかけたら「アホか」と思うでしょ？
＃ODBCが使えるのかどうかは知らない。
131 ：U ◆CZtFsGiu0c ：04/07/31 13:15 ID:???
>>123
>XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
DB全体で一つの文書、というのはまずないでしょうが、どの単位で一文書とするかは
設計次第ですね。
>・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
現状ではそのとおりです。
>・referenceは結局ID属性を使いまくりになる。
参照に関しては、XPointerやXLinkなどの技術がXML-DBに取り入れられるのを待つ必要
がありますね。
>・そのときの排他制御がどうなるのかいまひとつ分からない。
これは実装依存です。
>・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
XQL? XQueryのことですか? インデックスも実装依存ですね。
>なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
とはいっても、オブジェクトの変更に対する通知のみですので、RPC系技術の代替に
なるわけではありません。が、状態の変更をリアルタイムに把握する必要があるシステム
であれば、有効でしょう。
>XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、
DB全体で一つの文書、というのはまずないでしょうが、どの単位で一文書とするかは
設計次第ですね。
>・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
現状ではそのとおりです。
>・referenceは結局ID属性を使いまくりになる。
参照に関しては、XPointerやXLinkなどの技術がXML-DBに取り入れられるのを待つ必要
がありますね。
>・そのときの排他制御がどうなるのかいまひとつ分からない。
これは実装依存です。
>・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。
XQL? XQueryのことですか? インデックスも実装依存ですね。
>なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
とはいっても、オブジェクトの変更に対する通知のみですので、RPC系技術の代替に
なるわけではありません。が、状態の変更をリアルタイムに把握する必要があるシステム
であれば、有効でしょう。
132 ：NAME IS NULL：04/08/07 14:38 ID:???
Javaは言語でもあるが、Javaはプラットフォームでもある。
別にパソコンに限った話でもない。
将来、Javaに取って代わる言語が現れたとしたら、既存資産であるデータ（ＤＢ）
を使えるようなマッピングツールが出るであろう。でなければJavaに取って代わる
可能性はない。
それより先にそのDBMS製品が別のDBMS製品に取って代わられる可能性もある。
そのときに今までのデータの移し替えが容易にできなければならない。
では違うジャンルへのDBへの移行はどうであろうか。(RDBからOODB もしくは
OODBから次の世代へ）
移行できるかもしれない。コストにより移行が現実的でないかもしれない。
RDBではいろんな言語から使える。
なぜOODBはJavaだけなのか？ Java以外にオブジェクト指向言語が普及して
いないだけではないのか？
視点を変えてみる。
JavaではいろんなジャンルのDBMSが扱える。
実はそれだけの話なのかもしれない。
別にパソコンに限った話でもない。
将来、Javaに取って代わる言語が現れたとしたら、既存資産であるデータ（ＤＢ）
を使えるようなマッピングツールが出るであろう。でなければJavaに取って代わる
可能性はない。
それより先にそのDBMS製品が別のDBMS製品に取って代わられる可能性もある。
そのときに今までのデータの移し替えが容易にできなければならない。
では違うジャンルへのDBへの移行はどうであろうか。(RDBからOODB もしくは
OODBから次の世代へ）
移行できるかもしれない。コストにより移行が現実的でないかもしれない。
RDBではいろんな言語から使える。
なぜOODBはJavaだけなのか？ Java以外にオブジェクト指向言語が普及して
いないだけではないのか？
視点を変えてみる。
JavaではいろんなジャンルのDBMSが扱える。
実はそれだけの話なのかもしれない。
133 ：NAME IS NULL：04/08/07 14:47 ID:???
>>130
ベンダーの宣伝文句はベンダーの主張であり、アピールポイントです。
ですがそれが私たちユーザから見て、ベンダーの理想が実現するとは限らない。
なぜならそれはベンダーの理想だから。
Adobeの製品を使えば夢のようなデジタルでペーパーレスな世界が広がります。
マイクロソフトの製品を使えば、生産性が向上します。
別にどこのベンダーの製品でもいいですけど。
ほんとにそれが１００％実現した事がありますか？
身近なところで言えば、マイクロソフトの新OSが発表されるたびに、前回のOSのときも、
そのまえのOSの時も、同じ宣伝文句だったよなあとデジャブーを体感させられます。
ベンダーの宣伝文句はベンダーの主張であり、アピールポイントです。
ですがそれが私たちユーザから見て、ベンダーの理想が実現するとは限らない。
なぜならそれはベンダーの理想だから。
Adobeの製品を使えば夢のようなデジタルでペーパーレスな世界が広がります。
マイクロソフトの製品を使えば、生産性が向上します。
別にどこのベンダーの製品でもいいですけど。
ほんとにそれが１００％実現した事がありますか？
身近なところで言えば、マイクロソフトの新OSが発表されるたびに、前回のOSのときも、
そのまえのOSの時も、同じ宣伝文句だったよなあとデジャブーを体感させられます。
134 ：NAME IS NULL：04/08/09 11:56 ID:???
>>133
いや、「100%で非の打ち所がないかどうか」ということではなくて、理想と主
張と製品機能はそんなにぶれてないでしょ?と書いたつもりです。
「100%実現してないからタコだ｣なんて文句言っても、あんまり意味無いと思
います。悪口言ってストレス解消するならいいけど。
理想に向かって少しでもマシな状況になれば良しとすればいいんじゃないかな。
上のObjectStoreの例で言えば
・クライアントサーバ構成をとっている。
・宣伝文句では基幹システム向けとかポストRDBというふれこみだった。(今も?)
・にもかかわらず言語依存度が高い。→拡張性に問題があると考えられる(CODASYL時代へ逆戻り)
・アーキテクチャに起因する問題がありそう(クライアントクラッシュ)
という点から、ベンダの理想と主張と製品機能がそもそも噛み合っていないと
書いたつもりです。
いや、「100%で非の打ち所がないかどうか」ということではなくて、理想と主
張と製品機能はそんなにぶれてないでしょ?と書いたつもりです。
「100%実現してないからタコだ｣なんて文句言っても、あんまり意味無いと思
います。悪口言ってストレス解消するならいいけど。
理想に向かって少しでもマシな状況になれば良しとすればいいんじゃないかな。
上のObjectStoreの例で言えば
・クライアントサーバ構成をとっている。
・宣伝文句では基幹システム向けとかポストRDBというふれこみだった。(今も?)
・にもかかわらず言語依存度が高い。→拡張性に問題があると考えられる(CODASYL時代へ逆戻り)
・アーキテクチャに起因する問題がありそう(クライアントクラッシュ)
という点から、ベンダの理想と主張と製品機能がそもそも噛み合っていないと
書いたつもりです。
135 ：U ◆CZtFsGiu0c ：04/08/10 00:42 ID:???
>>132
JavaしかサポートしていないOODBってなんですか?
ほとんどの商用OODBはJavaの普及以前から存在するのですが。
問題なのは、例えばJavaプログラムからストアしたオブジェクトをC++プログラムから
扱えない、とかそういうことなのですが。
>>134
>・クライアントサーバ構成をとっている。
これ自体には問題はないと思うのですが、何か問題ありますか?
JavaしかサポートしていないOODBってなんですか?
ほとんどの商用OODBはJavaの普及以前から存在するのですが。
問題なのは、例えばJavaプログラムからストアしたオブジェクトをC++プログラムから
扱えない、とかそういうことなのですが。
>>134
>・クライアントサーバ構成をとっている。
これ自体には問題はないと思うのですが、何か問題ありますか?
136 ：NAME IS NULL：04/08/10 01:34 ID:???
>>135
> >・クライアントサーバ構成をとっている。
>
> これ自体には問題はないと思うのですが、何か問題ありますか?
書き方がわかりにくかったですが、箇条書きの１個目と２個目を受けて３個目
を書いています。
ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
しかし「クライアントサーバアーキテクチャ」といった場合には、アプリケー
ションが特定されないか、少なくとも数種類のアプリケーションは存在してい
るシステム構成を暗黙の前提としていたはずです。（Xサーバとかは又違う気
もしますが、ＤＢサーバを使った業務系システムということで）
ずっと名無しで書いているので、私のレスがどれか分かりづらくなってきたの
で、リファレンスをここで作っておくと、
>>40,42,58,60,63,66-68,77,79,84,86,88
>>89,93,94,99,101,103-105,112-114
>>116,121-124,126,129,130,133
です。
(結構多いなw)
何人で議論してるのかも分からなくなってきたw
> >・クライアントサーバ構成をとっている。
>
> これ自体には問題はないと思うのですが、何か問題ありますか?
書き方がわかりにくかったですが、箇条書きの１個目と２個目を受けて３個目
を書いています。
ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
しかし「クライアントサーバアーキテクチャ」といった場合には、アプリケー
ションが特定されないか、少なくとも数種類のアプリケーションは存在してい
るシステム構成を暗黙の前提としていたはずです。（Xサーバとかは又違う気
もしますが、ＤＢサーバを使った業務系システムということで）
ずっと名無しで書いているので、私のレスがどれか分かりづらくなってきたの
で、リファレンスをここで作っておくと、
>>40,42,58,60,63,66-68,77,79,84,86,88
>>89,93,94,99,101,103-105,112-114
>>116,121-124,126,129,130,133
です。
(結構多いなw)
何人で議論してるのかも分からなくなってきたw
137 ：U ◆CZtFsGiu0c ：04/08/10 11:56 ID:???
>>136
>ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
テクチャを想定していませんか? だとすると、それは勘違いですよ。それに
OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
アプリケーションでしか使えないなんてことはありません。
＃だから組み込み云々って話になっていたのか
>ObjectStore(あるいはOODB一般？)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。
もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
テクチャを想定していませんか? だとすると、それは勘違いですよ。それに
OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
アプリケーションでしか使えないなんてことはありません。
＃だから組み込み云々って話になっていたのか
ODB(もどき)を自作しているか自作してみたい人いませんか？
139 ：NAME IS NULL：04/08/10 14:04 ID:???
>>137
> もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
> テクチャを想定していませんか? だとすると、それは勘違いですよ。
いわゆるサーバが起動していて、クライアントも実行されて、クライアントか
らサーバへリクエストが飛んで、その結果がクライアントへ帰ってくる、とい
うようなものを想定してました。Page faultでも似たようなものだと思ってい
ます。
「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
「クライアント/サーバ」に厳密な定義があるわけじゃない、別物だとしたら
SI市場に向けて「クライアント/サーバ」というメッセージを発信することは
やっぱり変だと思います。
＃話がうまく噛み合ってるかな?
> それに
> OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
> アプリケーションでしか使えないなんてことはありません。
> ＃だから組み込み云々って話になっていたのか
うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
で、そこから上の方で書いたような「設計の成果がどの程度の汎用性を持ちう
るのか」という疑問に繋がります。
この辺の感覚がどのぐらいなのか分からないのですが、安心して出せるガイド
ラインとか、｢どんなときにどんな風に使えばいいの?｣という疑問に対しては
「特定のアプリ専用」とか「組み込み」という感じにならざるを得ないのかな、
という予想です。
> もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
> テクチャを想定していませんか? だとすると、それは勘違いですよ。
いわゆるサーバが起動していて、クライアントも実行されて、クライアントか
らサーバへリクエストが飛んで、その結果がクライアントへ帰ってくる、とい
うようなものを想定してました。Page faultでも似たようなものだと思ってい
ます。
「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
「クライアント/サーバ」に厳密な定義があるわけじゃない、別物だとしたら
SI市場に向けて「クライアント/サーバ」というメッセージを発信することは
やっぱり変だと思います。
＃話がうまく噛み合ってるかな?
> それに
> OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
> アプリケーションでしか使えないなんてことはありません。
> ＃だから組み込み云々って話になっていたのか
うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
で、そこから上の方で書いたような「設計の成果がどの程度の汎用性を持ちう
るのか」という疑問に繋がります。
この辺の感覚がどのぐらいなのか分からないのですが、安心して出せるガイド
ラインとか、｢どんなときにどんな風に使えばいいの?｣という疑問に対しては
「特定のアプリ専用」とか「組み込み」という感じにならざるを得ないのかな、
という予想です。
140 ：U ◆CZtFsGiu0c ：04/08/10 14:30 ID:???
>>139
>「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
>うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
>「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。
そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
>うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。
だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
141 ：NAME IS NULL：04/08/10 15:43 ID:???
>>140
> そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
> 限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
その通りです。で、それを受けて>>134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
> >うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
> というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
> 意図です。
>
> だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
RDBMSでもそうした問題が皆無じゃないでしょうが、はるかにマシだと思います。
0 や100じゃないからみんな同じと考えるわけにもいかないでしょ?
○特定のアプリを想定せずに設計する(本当に何も想定しないのは不可能です
が、指向性としてベースの設計は)。
OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
その結果、例えばクラス構成をガラッと変える可能性よりも、正規化したテー
ブル構成をガラッと変える確率のほうが低いと思います。(←根拠となるデータは有りません。)
あるいは、クラスやその中の属性の永続性を意識しながら設計するノウハウが
一般的に浸透している状況なのでしょうか。
○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
RDB系では機構としては、追加した項目を使わないアプリはそのままでOKです。
これはOODBでは何らかのケアがあるんでしょうか?(Objectivityには何かあっ
たようなおぼろげな記憶があるけど勘違いかも。)
○更に、これは最近考えているんですが、RDB系ではクライアントがある情報
エントリを指定するためにコード(ID)やSQL文といった文字列を使うためにク
ライアント−サーバ間の結合度がlooseになっていますが、OODBでは変数名・
配列名・添字などがそれに相当しています。
そのためソース全体にわたってハードコーディングされた状態になっているた
め、クライアント−サーバ間の結合度がtightになってしまい、RDBに比べて柔
軟性に欠けて使いづらくなっているのではないでしょうか。
XMLを使えばもっとlooseになって接続の柔軟性が増すでしょうね。(今のとこ
ろクライアント−サーバ間よりもシステム間接続で人気みたいですが)
＃最後の主張は最近思いついたので、多分穴有りまくり。
> そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
> 限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。
その通りです。で、それを受けて>>134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
> >うーん特定のアプリというと御幣があったかもしれないけど、｢特定の設計」
> というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
> 意図です。
>
> だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。
RDBMSでもそうした問題が皆無じゃないでしょうが、はるかにマシだと思います。
0 や100じゃないからみんな同じと考えるわけにもいかないでしょ?
○特定のアプリを想定せずに設計する(本当に何も想定しないのは不可能です
が、指向性としてベースの設計は)。
OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
その結果、例えばクラス構成をガラッと変える可能性よりも、正規化したテー
ブル構成をガラッと変える確率のほうが低いと思います。(←根拠となるデータは有りません。)
あるいは、クラスやその中の属性の永続性を意識しながら設計するノウハウが
一般的に浸透している状況なのでしょうか。
○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
RDB系では機構としては、追加した項目を使わないアプリはそのままでOKです。
これはOODBでは何らかのケアがあるんでしょうか?(Objectivityには何かあっ
たようなおぼろげな記憶があるけど勘違いかも。)
○更に、これは最近考えているんですが、RDB系ではクライアントがある情報
エントリを指定するためにコード(ID)やSQL文といった文字列を使うためにク
ライアント−サーバ間の結合度がlooseになっていますが、OODBでは変数名・
配列名・添字などがそれに相当しています。
そのためソース全体にわたってハードコーディングされた状態になっているた
め、クライアント−サーバ間の結合度がtightになってしまい、RDBに比べて柔
軟性に欠けて使いづらくなっているのではないでしょうか。
XMLを使えばもっとlooseになって接続の柔軟性が増すでしょうね。(今のとこ
ろクライアント−サーバ間よりもシステム間接続で人気みたいですが)
＃最後の主張は最近思いついたので、多分穴有りまくり。
142 ：U ◆CZtFsGiu0c ：04/08/10 16:14 ID:???
>>140
>その通りです。で、それを受けて>>134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
「時代に逆行」というか、キャッシュアーキテクチャを取っているための
トレードオフと考えたほうがいいでしょう。キャッシュにロードされる
オブジェクトのトータルサイズが、キャッシュサイズに収まればいいわけ
なので、システム設計時にサイジングをきっちりおこなっていれば問題
ないわけです。
＃ま、理想論なのは承知しています
>OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
>○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
確かにObjectStoreでは大変でした。現バージョンでは改善されているかも
しれませんけどね。XPで有名なKent Beckは「日々のスキーマ更新」を
プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
はスキーマ更新が簡単なのですかね?
>その通りです。で、それを受けて>>134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。
「時代に逆行」というか、キャッシュアーキテクチャを取っているための
トレードオフと考えたほうがいいでしょう。キャッシュにロードされる
オブジェクトのトータルサイズが、キャッシュサイズに収まればいいわけ
なので、システム設計時にサイジングをきっちりおこなっていれば問題
ないわけです。
＃ま、理想論なのは承知しています
>OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?
OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
>○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
確かにObjectStoreでは大変でした。現バージョンでは改善されているかも
しれませんけどね。XPで有名なKent Beckは「日々のスキーマ更新」を
プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
はスキーマ更新が簡単なのですかね?
143 ：NAME IS NULL：04/08/10 17:04 ID:???
>>142
> 「時代に逆行」というか、キャッシュアーキテクチャを取っているための
> トレードオフと考えたほうがいいでしょう。
「キャッシュアーキテクチャ」を主眼にとっているのなら、やはり｢クライア
ント−サーバ」とはレイヤが異なっていると感じます。
どちらかというと「共有メモリ」とか「ソケット」に近いんじゃないでしょうか。
「システムをクライアントサーバ方式で構築する」とは言っても「システムを
共有メモリ方式で構築する」というのは違和感を覚えます。
｢共有メモリ」を無理やりシステム方式のレイヤへ持ってくるようなおかしさ
を上のキャッシュアーキテクチャでは感じます。
他のOODBではサーバへOIDをリクエストして、目的のオブジェクトをクライア
ントが取得すると思うので、こうしたことは当てはまらないと思いますが。
> OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
> 変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
その通り、変わりません。設計に問題が出やすいかどうかです。以下は私の感
じていることなのでプログラミング畑の人のほうが距離感がわくでしょうから
コメントが欲しいところ。
RDB系の場合、DB設計担当者が永続化に特化して作業します。また、機構上ア
プリの構造が入り込むことはありえません。
(だからアプリ設計者からSQLへの不満が出てくるわけで)
OODBの場合はどうなるんでしょうか?
アプリ設計者がDB設計者も兼ねるのなら、OO設計で永続性に注意してクラスを
区分するような設計が望めるのでしょうか。(これは上の方に書いたレコード
設計とジャンプテーブル設計に関する文化の懸念)
＃ObjectStoreの場合、どういう永続化設計をしなきゃいけないのかは知らないです。
永続化クラスを専門に設計する担当者がいるのなら、そのクラスを使うアプリ
設計者は設計の自由度が無いと感じたり、「作ったクラスがそのまま永続化」
というOODBが目指した利点を享受できないことにならないでしょうか。
その永続化クラス設計者はクライアントのアプリケーション特性、マシン環境
と共にサーバのマシン環境やネットワークにまで考慮が必要となり、求められ
る技術スキルがRDBと比べて驚異的に高くなってしまい、敷居が高くならない
でしょうか。
> XPで有名なKent Beckは「日々のスキーマ更新」を
> プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
> はスキーマ更新が簡単なのですかね?
GemStoneはSmalltalkベースですからC++ベースのものよりはやりやすいかもし
れませんね。(←単なる印象論)
XP(というかオブジェクト指向も含むプログラミング関連トピック全般)は「す
でに保存したデータ」に関しては何も考慮していないんじゃないでしょうか。
で、現実はそうもいかないからDBにアクセスしなきゃいけなくなって「面倒く
さいな」と不満が出る。
> 「時代に逆行」というか、キャッシュアーキテクチャを取っているための
> トレードオフと考えたほうがいいでしょう。
「キャッシュアーキテクチャ」を主眼にとっているのなら、やはり｢クライア
ント−サーバ」とはレイヤが異なっていると感じます。
どちらかというと「共有メモリ」とか「ソケット」に近いんじゃないでしょうか。
「システムをクライアントサーバ方式で構築する」とは言っても「システムを
共有メモリ方式で構築する」というのは違和感を覚えます。
｢共有メモリ」を無理やりシステム方式のレイヤへ持ってくるようなおかしさ
を上のキャッシュアーキテクチャでは感じます。
他のOODBではサーバへOIDをリクエストして、目的のオブジェクトをクライア
ントが取得すると思うので、こうしたことは当てはまらないと思いますが。
> OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
> 変わらないはずです。逆に変わるとすると設計に問題があるでしょう。
その通り、変わりません。設計に問題が出やすいかどうかです。以下は私の感
じていることなのでプログラミング畑の人のほうが距離感がわくでしょうから
コメントが欲しいところ。
RDB系の場合、DB設計担当者が永続化に特化して作業します。また、機構上ア
プリの構造が入り込むことはありえません。
(だからアプリ設計者からSQLへの不満が出てくるわけで)
OODBの場合はどうなるんでしょうか?
アプリ設計者がDB設計者も兼ねるのなら、OO設計で永続性に注意してクラスを
区分するような設計が望めるのでしょうか。(これは上の方に書いたレコード
設計とジャンプテーブル設計に関する文化の懸念)
＃ObjectStoreの場合、どういう永続化設計をしなきゃいけないのかは知らないです。
永続化クラスを専門に設計する担当者がいるのなら、そのクラスを使うアプリ
設計者は設計の自由度が無いと感じたり、「作ったクラスがそのまま永続化」
というOODBが目指した利点を享受できないことにならないでしょうか。
その永続化クラス設計者はクライアントのアプリケーション特性、マシン環境
と共にサーバのマシン環境やネットワークにまで考慮が必要となり、求められ
る技術スキルがRDBと比べて驚異的に高くなってしまい、敷居が高くならない
でしょうか。
> XPで有名なKent Beckは「日々のスキーマ更新」を
> プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
> はスキーマ更新が簡単なのですかね?
GemStoneはSmalltalkベースですからC++ベースのものよりはやりやすいかもし
れませんね。(←単なる印象論)
XP(というかオブジェクト指向も含むプログラミング関連トピック全般)は「す
でに保存したデータ」に関しては何も考慮していないんじゃないでしょうか。
で、現実はそうもいかないからDBにアクセスしなきゃいけなくなって「面倒く
さいな」と不満が出る。
144 ：NAME IS NULL：04/08/15 01:31 ID:eZJV+s8t
RDB、OODBのどちらが100年後に残っているか
と聞かれたら
OODBに賭けるな。。
と聞かれたら
OODBに賭けるな。。
145 ：NAME IS NULL：04/08/15 01:37 ID:???
146 ：NAME IS NULL：04/08/15 01:42 ID:eZJV+s8t
他の言語からアクセスできないのは
ObjectStoreだけじゃないかな。。
仮想メモリーを使って、そのままオブジェクトをPersistentにするって
Pointer-swizzlingだったけ？
ObjectOtoreが特許持ってるんだよね。
ObjectStoreだけじゃないかな。。
仮想メモリーを使って、そのままオブジェクトをPersistentにするって
Pointer-swizzlingだったけ？
ObjectOtoreが特許持ってるんだよね。
147 ：NAME IS NULL：04/08/15 02:49 ID:???
>>146
pointer swizzling という言葉を知らなかったのでググってみた。
永続ポインタを管理する手法のひとつで、類語として
hardware swizzling というのがあるみたいだね。
ええー、でもさ、「ページイン＆ページアウトを契機に
他のホストと共有しているメモリオブジェクトの整合性を図る」ってのは、
いろんな分散共有メモリ(Distributed Shared Memory)の実装で
利用されてる方法と認識してる。
複数ホストでポインタを含むデータを効率よく共有しようとしたら
必然的にそうなるのでは。
特許になってるとしたら問題かも。ほんとに特許になってるの？
pointer swizzling という言葉を知らなかったのでググってみた。
永続ポインタを管理する手法のひとつで、類語として
hardware swizzling というのがあるみたいだね。
ええー、でもさ、「ページイン＆ページアウトを契機に
他のホストと共有しているメモリオブジェクトの整合性を図る」ってのは、
いろんな分散共有メモリ(Distributed Shared Memory)の実装で
利用されてる方法と認識してる。
複数ホストでポインタを含むデータを効率よく共有しようとしたら
必然的にそうなるのでは。
特許になってるとしたら問題かも。ほんとに特許になってるの？
148 ：NAME IS NULL：04/08/15 03:08 ID:???
>>144
RDBの考え方（表があればいろんなデータを貯蔵できる）は
数学の理論みたいなもんだから100年後も残ってると思う。
そのかわり問い合わせ言語はもっといいのが出てると思う。
SQLって確かIBMでしょ？昔はクエイルとかシークエルとか
いろいろあったらしいし。
オブジェクトDBの考え方は、「オブジェクトを払い出す」
という意味で分散オブジェクトの仕組みと統合されていくのでは。
そんでそれは分散共有メモリ（つまりホスト間での共有メモリ）とも
非常に近いと思うよのさ。
RDBの考え方（表があればいろんなデータを貯蔵できる）は
数学の理論みたいなもんだから100年後も残ってると思う。
そのかわり問い合わせ言語はもっといいのが出てると思う。
SQLって確かIBMでしょ？昔はクエイルとかシークエルとか
いろいろあったらしいし。
オブジェクトDBの考え方は、「オブジェクトを払い出す」
という意味で分散オブジェクトの仕組みと統合されていくのでは。
そんでそれは分散共有メモリ（つまりホスト間での共有メモリ）とも
非常に近いと思うよのさ。
149 ：NAME IS NULL：04/08/23 17:12 ID:???
>>147
pointer swizzlingはOODB界隈では、メモリ上でポインタを辿る操作をディス
ク上での同等の操作へ置き換える、という文脈で使われていたと思います。だ
からObject Serverでも良いし、極端には裏でSQLが発行されていても良いんじゃ
ないかな。
「共有メモリ」の使い方としては、そこへread/writeするためのフォーマット
をアプリとは別に設計すると思っていたんだけど、分散共有メモリだとまた違
うんでしょうか。
多分｢共有メモリを分散する」時にPage Faultを利用するんじゃないかな。(詳
しく知らないけど)
アプリケーションのPage Faultを契機に動作するのは、より正確には「共有ス
ワップ領域」と考えた方が良いんじゃないでしょうか。そんな低レベルの機構
を表にむき出しにしてどうやって活用するのかいまいち分からないし、
ObjectStoreから何か提案されていた記憶もない。
今にして思えば｢クライアント･サーバ｣と言うよりも「P2P」と呼んだ方が近かっ
たのかも。(それでもP2Pでシステムを構築するイメージがつかめないけど)
特許に関しては、10年ほど前のパンフレットに｢特許出願中｣と書いてあるのを
見ただけで、実際に成立したかどうかは知らないです。
pointer swizzlingはOODB界隈では、メモリ上でポインタを辿る操作をディス
ク上での同等の操作へ置き換える、という文脈で使われていたと思います。だ
からObject Serverでも良いし、極端には裏でSQLが発行されていても良いんじゃ
ないかな。
「共有メモリ」の使い方としては、そこへread/writeするためのフォーマット
をアプリとは別に設計すると思っていたんだけど、分散共有メモリだとまた違
うんでしょうか。
多分｢共有メモリを分散する」時にPage Faultを利用するんじゃないかな。(詳
しく知らないけど)
アプリケーションのPage Faultを契機に動作するのは、より正確には「共有ス
ワップ領域」と考えた方が良いんじゃないでしょうか。そんな低レベルの機構
を表にむき出しにしてどうやって活用するのかいまいち分からないし、
ObjectStoreから何か提案されていた記憶もない。
今にして思えば｢クライアント･サーバ｣と言うよりも「P2P」と呼んだ方が近かっ
たのかも。(それでもP2Pでシステムを構築するイメージがつかめないけど)
特許に関しては、10年ほど前のパンフレットに｢特許出願中｣と書いてあるのを
見ただけで、実際に成立したかどうかは知らないです。
150 ：NAME IS NULL：04/08/23 17:20 ID:???
>>148
SEQUELが今のSQLらしいです。
http://www-6.ibm.com/jp/software/data/developer/column/iroha/23.html
DBMSとして成立するには検索(インデックス)とトランザクション管理･排他制
御と運用支援が必須だと思うんですが、分散オブジェクト界隈ではそうした方
面のことは考えられているんでしょうか。
逆に言えばその3つさえあれば、アクセスするためのインタフェースがSQLでも
オブジェクトでもXMLでも後は好みの問題に過ぎないと思う。
SEQUELが今のSQLらしいです。
http://www-6.ibm.com/jp/software/data/developer/column/iroha/23.html
DBMSとして成立するには検索(インデックス)とトランザクション管理･排他制
御と運用支援が必須だと思うんですが、分散オブジェクト界隈ではそうした方
面のことは考えられているんでしょうか。
逆に言えばその3つさえあれば、アクセスするためのインタフェースがSQLでも
オブジェクトでもXMLでも後は好みの問題に過ぎないと思う。
151 ：NAME IS NULL：04/08/24 22:59 ID:???
OODB と RDB ではデータ設計自体が異なる。RDB では親が複数の子を持つことができず、
それぞれの子が親へのポインタを持たざるを得ない。たとえば、伝票ヘッダと
伝票明細が 1:N の関係であるとき、伝票ヘッダには、従属する伝票明細へのポインタを
持たせることができず、伝票明細に親である伝票ヘッダの主キー(伝票番号)を持たせる、
という構造になる。そして、伝票ヘッダ(伝票番号=123)の明細を取得しようと思ったときに、
伝票番号=123 を持つ伝票明細を検索することで、親から子を辿ったのと同じ結果を得る。
これは、データを横断的に検索できるという RDB-SQL の特性を利用してはいるが、
本来の横断的なデータベース検索とは本質的に異なる。
親が子の情報を持てないために、検索機能を利用しているだけで、
2004/08/01〜2004/08/31 の伝票明細を検索するなどの横断的検索とは違うのである。
これが、オブジェクト指向になると、もっと直感的に設計ができる。
つまり、親に子の情報を持たせることができる。コレクションなり配列なりを
使用することによって。
オブジェクト指向(言語)では、現実の事象をオブジェクトとしてモデリングすることを
身上としている。これは非常に直感的で分かりやすい構造を維持できるからだ。
対して、RDB では利用方法を想定して、非直感的な設計を余儀なくされることがある。
上記の子に親のポインタを持たせるというのは、そうしないと辿れなくなってしまうから、
そうしているのであって、現実の事象を直接的にモデル化しているとは言いがたい。
それぞれの子が親へのポインタを持たざるを得ない。たとえば、伝票ヘッダと
伝票明細が 1:N の関係であるとき、伝票ヘッダには、従属する伝票明細へのポインタを
持たせることができず、伝票明細に親である伝票ヘッダの主キー(伝票番号)を持たせる、
という構造になる。そして、伝票ヘッダ(伝票番号=123)の明細を取得しようと思ったときに、
伝票番号=123 を持つ伝票明細を検索することで、親から子を辿ったのと同じ結果を得る。
これは、データを横断的に検索できるという RDB-SQL の特性を利用してはいるが、
本来の横断的なデータベース検索とは本質的に異なる。
親が子の情報を持てないために、検索機能を利用しているだけで、
2004/08/01〜2004/08/31 の伝票明細を検索するなどの横断的検索とは違うのである。
これが、オブジェクト指向になると、もっと直感的に設計ができる。
つまり、親に子の情報を持たせることができる。コレクションなり配列なりを
使用することによって。
オブジェクト指向(言語)では、現実の事象をオブジェクトとしてモデリングすることを
身上としている。これは非常に直感的で分かりやすい構造を維持できるからだ。
対して、RDB では利用方法を想定して、非直感的な設計を余儀なくされることがある。
上記の子に親のポインタを持たせるというのは、そうしないと辿れなくなってしまうから、
そうしているのであって、現実の事象を直接的にモデル化しているとは言いがたい。
152 ：U ◆CZtFsGiu0c ：04/08/24 23:51 ID:???
>>150
トランザクションをサポートしていないデータベースなんて使えないですよ:-)
インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
と思います。また、排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
最悪デッドロックの嵐になります。
トランザクションをサポートしていないデータベースなんて使えないですよ:-)
インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
と思います。また、排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
最悪デッドロックの嵐になります。
153 ：NAME IS NULL：04/08/25 00:40 ID:???
>>149
「共有スワップ領域」はお見事。頂いとく（笑
>>150
サンQueue。
>>151の言うことは確かにうなずける。勢い込んでうんうんとやってしまった。
ところが>>152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
おいらは階層型DBもネットワーク型DBも触ったことないんだが、
当時遅いと言われたらしいRDBがなぜこれだけ発展して、
前記２つがなぜ廃れたか、誰か知らないかな。
手元のモデリング本も参照してちょっと想像してみたのだが、
階層型：無理にでも木構造にしないとだめ。表現力乏しい。
→XMLDBもそうじゃないか？
ネットワーク型：表現力ありすぎ、複雑になってメンテ困難。
well formedな形についての理論が未完成。
→オブジェクトDBもそうじゃないか？
うーむ、もしかしたらリレーショナルの良さは程ほど具合？
直接ポイントできるのは親方向だけで、
子方向には検索という形でしかポイントできない、ということに
結構意味があるのかも知れないなぁ。
「共有スワップ領域」はお見事。頂いとく（笑
>>150
サンQueue。
>>151の言うことは確かにうなずける。勢い込んでうんうんとやってしまった。
ところが>>152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
おいらは階層型DBもネットワーク型DBも触ったことないんだが、
当時遅いと言われたらしいRDBがなぜこれだけ発展して、
前記２つがなぜ廃れたか、誰か知らないかな。
手元のモデリング本も参照してちょっと想像してみたのだが、
階層型：無理にでも木構造にしないとだめ。表現力乏しい。
→XMLDBもそうじゃないか？
ネットワーク型：表現力ありすぎ、複雑になってメンテ困難。
well formedな形についての理論が未完成。
→オブジェクトDBもそうじゃないか？
うーむ、もしかしたらリレーショナルの良さは程ほど具合？
直接ポイントできるのは親方向だけで、
子方向には検索という形でしかポイントできない、ということに
結構意味があるのかも知れないなぁ。
154 ：NAME IS NULL：04/08/25 00:52 ID:26RWSsaC
ところで >>150 のページは、内容に対して
著者イラストが若すぎる気がしないか？age
著者イラストが若すぎる気がしないか？age
155 ：NAME IS NULL：04/08/25 15:09 ID:???
＃あまり過度にRDBの肩を持つのも嫌だけど。
>>151
設計というよりも実装の話ですよね?
オブジェクト指向でも親が子の情報を持つわけではなくて、子へのポインタを
持つだけなんじゃないでしょうか。設計において親子関係であることを定義す
ることって出来ましたっけ?(継承時にサブクラスであると宣言するように。)
設計者と利用者の間で合意を取っているだけだと思います。
RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
「left outer join」に相当するわけだし。
OODBだと単純に持たせただけだと、子から親へ辿るのがめんどくさくなっちゃうでしょ?
特定の明細件名をもっている伝票番号一覧を出すとか。
＃双方向リンク用のライブラリ等がどのぐらい普及しているものなのかはよく
知りません。
オブジェクト指向でも「期間を限定した伝票明細の検索」は、「検索」機能を
利用するでしょう? キーを指定してサーバへリクエストする代わりに、属性
名や配列の添え字がソースコード中にハードコーディングされているし。
＃私はRDBのjoinとOODBのpointer traverseは設計上の意味合いはほぼ同じと
＃考えているけど、ここは合意が取れるのかな。
RDBで明らかに足りない、あるいは普及していないのは、型チェック機能など
でしょうね。
IDの更新に対する保護機能も無いし。
>>151
設計というよりも実装の話ですよね?
オブジェクト指向でも親が子の情報を持つわけではなくて、子へのポインタを
持つだけなんじゃないでしょうか。設計において親子関係であることを定義す
ることって出来ましたっけ?(継承時にサブクラスであると宣言するように。)
設計者と利用者の間で合意を取っているだけだと思います。
RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
「left outer join」に相当するわけだし。
OODBだと単純に持たせただけだと、子から親へ辿るのがめんどくさくなっちゃうでしょ?
特定の明細件名をもっている伝票番号一覧を出すとか。
＃双方向リンク用のライブラリ等がどのぐらい普及しているものなのかはよく
知りません。
オブジェクト指向でも「期間を限定した伝票明細の検索」は、「検索」機能を
利用するでしょう? キーを指定してサーバへリクエストする代わりに、属性
名や配列の添え字がソースコード中にハードコーディングされているし。
＃私はRDBのjoinとOODBのpointer traverseは設計上の意味合いはほぼ同じと
＃考えているけど、ここは合意が取れるのかな。
RDBで明らかに足りない、あるいは普及していないのは、型チェック機能など
でしょうね。
IDの更新に対する保護機能も無いし。
156 ：NAME IS NULL：04/08/25 15:19 ID:???
>>152
> トランザクションをサポートしていないデータベースなんて使えないですよ:-)
だからインタフェースよりもそっちの方が重要だし、コンパイラに渡す文字列
を書きやすくするためにそっちへしわ寄せが行っていないか、十分検討したい
です。
> インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
> と思います。
ObjectStoreの「コレクション」は普通の意味とニュアンスが違っていたよう
な。Collection型とかとは違うんですよね?
> 排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
> 単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
> するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
> 最悪デッドロックの嵐になります。
＃クラスタ単位がどのようなものか分からないので外しているかもしれませんが。
「仮想ページがそのまま」というのから想像すると、コンパイラをhackしてヒー
プ領域の使い方を指示できる、という理解で良いでしょうか。
そこまでする必要があるなら「プログラム実行イメージをそのまま格納」と言
うだけのためには、あまりにも汚くて他の部分への負担が大きいように思います。
Page Faultを契機にしたPage Serverにこだわるよりも、pointer traversalを
契機にしたObject Serverの方がまだ使いやすそうな印象を受けます。
> トランザクションをサポートしていないデータベースなんて使えないですよ:-)
だからインタフェースよりもそっちの方が重要だし、コンパイラに渡す文字列
を書きやすくするためにそっちへしわ寄せが行っていないか、十分検討したい
です。
> インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
> と思います。
ObjectStoreの「コレクション」は普通の意味とニュアンスが違っていたよう
な。Collection型とかとは違うんですよね?
> 排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
> 単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
> するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
> 最悪デッドロックの嵐になります。
＃クラスタ単位がどのようなものか分からないので外しているかもしれませんが。
「仮想ページがそのまま」というのから想像すると、コンパイラをhackしてヒー
プ領域の使い方を指示できる、という理解で良いでしょうか。
そこまでする必要があるなら「プログラム実行イメージをそのまま格納」と言
うだけのためには、あまりにも汚くて他の部分への負担が大きいように思います。
Page Faultを契機にしたPage Serverにこだわるよりも、pointer traversalを
契機にしたObject Serverの方がまだ使いやすそうな印象を受けます。
157 ：NAME IS NULL：04/08/25 15:32 ID:???
>>153
> ところが>>152を見て思ったのは、双方向にリンクできると
> 設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
いや、それよりもPage Serverであるがゆえにロックがページ単位となり、コ
ンパイラが仮想ページの中にどのようにオブジェクトを配置するかを理解する
必要がある、ということではないでしょうか。
> おいらは階層型DBもネットワーク型DBも触ったことないんだが、
> 当時遅いと言われたらしいRDBがなぜこれだけ発展して、
> 前記２つがなぜ廃れたか、誰か知らないかな。
はるか上のほうでも書きましたが、UNIX・クライアントサーバブームが訪れた
ときに、そのプラットフォーム上でCSモデルを構築できるのがRDBしか無かっ
たからではないでしょうか。で、Oracleなんかはその流れを逃さずにホスト版
のOracleをUNIXへ移植して売り込み攻勢をかけたと。
だからOracleのコマンドラインツールはUNIXっぽくもWindowsっぽくも無くて、
なんか変な感じでしょ?(もう何年も触ってないけど)
他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
> ところが>>152を見て思ったのは、双方向にリンクできると
> 設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
いや、それよりもPage Serverであるがゆえにロックがページ単位となり、コ
ンパイラが仮想ページの中にどのようにオブジェクトを配置するかを理解する
必要がある、ということではないでしょうか。
> おいらは階層型DBもネットワーク型DBも触ったことないんだが、
> 当時遅いと言われたらしいRDBがなぜこれだけ発展して、
> 前記２つがなぜ廃れたか、誰か知らないかな。
はるか上のほうでも書きましたが、UNIX・クライアントサーバブームが訪れた
ときに、そのプラットフォーム上でCSモデルを構築できるのがRDBしか無かっ
たからではないでしょうか。で、Oracleなんかはその流れを逃さずにホスト版
のOracleをUNIXへ移植して売り込み攻勢をかけたと。
だからOracleのコマンドラインツールはUNIXっぽくもWindowsっぽくも無くて、
なんか変な感じでしょ?(もう何年も触ってないけど)
他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
158 ：U ◆CZtFsGiu0c ：04/08/25 17:00 ID:???
>>153
ところが>>152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
ページロックしかサポートしていないRDBMSで、一つのページに複数のテーブルの
レコードがランダムに存在している状態を想像してみてください:-)
>>155
同意します。オブジェクトモデルをデータモデルに落とすのは、それほど難しく
ありません。もちろん再帰的な構造を持つものなど、悩ましいものはありますが。
RDBがいいのは、テーブル間の物理的な関係が疎なために、アドホックな参照や
メンテナンスがやりやすいことですね。
>>157
汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
ですが。
>他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
C/S全盛の時代より前にありましたよ。
ところが>>152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな？ということ。
ページロックしかサポートしていないRDBMSで、一つのページに複数のテーブルの
レコードがランダムに存在している状態を想像してみてください:-)
>>155
同意します。オブジェクトモデルをデータモデルに落とすのは、それほど難しく
ありません。もちろん再帰的な構造を持つものなど、悩ましいものはありますが。
RDBがいいのは、テーブル間の物理的な関係が疎なために、アドホックな参照や
メンテナンスがやりやすいことですね。
>>157
汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
ですが。
>他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。
C/S全盛の時代より前にありましたよ。
159 ：NAME IS NULL：04/08/25 17:50 ID:???
>>158
> >>157
> 汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
> Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
> ですが。
探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。
http://infoboerse.doag.de/mirror/frank/faqora.htm#HIST
> C/S全盛の時代より前にありましたよ。
でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな？
トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。
> >>157
> 汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
> Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
> ですが。
探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。
http://infoboerse.doag.de/mirror/frank/faqora.htm#HIST
> C/S全盛の時代より前にありましたよ。
でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな？
トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。
160 ：U ◆CZtFsGiu0c ：04/08/25 20:13 ID:???
>>159
>探してみたら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はそれに乗り遅れた、と。
>探してみたら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はそれに乗り遅れた、と。
161 ：NAME IS NULL：04/08/25 21:59 ID:???
> 設計というよりも実装の話ですよね?
実装(制限)に合わせた設計を要求されるということある。
これは、実際のデータモデリングとは異なるスキーマ定義を
しなければいけなくなることがある、ということを意味する。
> RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
> ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
> 「left outer join」に相当するわけだし。
left outer join を使うこと自体がトリックなのである。
left outer join はポインタを辿る操作であるが、A left outer join B とは
"A から B を辿る" ことを意味する。>>151 で例示した問題では、
"伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
これは、子から親を辿っていることに他ならない。
ここで、ひとつ考えてみて欲しい。その元となる子(伝票明細)の集合は
どのようにして集めるのだろうか？ 伝票番号=123 を取り出したいとき、
伝票番号=123 を持つ伝票明細を取り出し、外結合によって伝票ヘッダを
辿ることになる。これは明らかに問題が前後している。伝票ヘッダを辿る前に、
伝票ヘッダの主要素である伝票番号を伝票明細は利用しなければならないのだから。
RDB の設計に慣れた人間ほど、この問題を意識することができない。
得たい結果から、無意識のうちに RDB式のスキーマ設計を行えるようように
訓練されてしまっているからだ。
この伝票問題の設計において、ルーキーが次のような愚かな設計をすることがある。
伝票 1枚あたりの明細数が最大10明細であると決めうち、伝票ヘッダに
伝票明細1行目, 伝票明細2行目, ･･･, 伝票明細10行目 と子へのポインタを
持たせてしまうのだ。これは RDB の設計としては明らかに誤りである。
正規化されていないために、商品A を購入している伝票を検索することが
できなくなってしまうのだから。
しかし、この発想を頭ごなしに否定してはいけない。この発想こそ直接的モデル化なのである。
発想自体は非常に分かりやすく直感的なものである。ただ、RDB においてはスキーマで
表現できないために、「誤り」として否定せざるを得ないだけのことである。このルーキーの
設計を馬鹿にする前に、この発想を直接的にモデル化できない RDB の制限についても
考えてみてもらいたい。RDB がモデル化において完全ではないことが次第に見えてくる。
実装(制限)に合わせた設計を要求されるということある。
これは、実際のデータモデリングとは異なるスキーマ定義を
しなければいけなくなることがある、ということを意味する。
> RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
> ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
> 「left outer join」に相当するわけだし。
left outer join を使うこと自体がトリックなのである。
left outer join はポインタを辿る操作であるが、A left outer join B とは
"A から B を辿る" ことを意味する。>>151 で例示した問題では、
"伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
これは、子から親を辿っていることに他ならない。
ここで、ひとつ考えてみて欲しい。その元となる子(伝票明細)の集合は
どのようにして集めるのだろうか？ 伝票番号=123 を取り出したいとき、
伝票番号=123 を持つ伝票明細を取り出し、外結合によって伝票ヘッダを
辿ることになる。これは明らかに問題が前後している。伝票ヘッダを辿る前に、
伝票ヘッダの主要素である伝票番号を伝票明細は利用しなければならないのだから。
RDB の設計に慣れた人間ほど、この問題を意識することができない。
得たい結果から、無意識のうちに RDB式のスキーマ設計を行えるようように
訓練されてしまっているからだ。
この伝票問題の設計において、ルーキーが次のような愚かな設計をすることがある。
伝票 1枚あたりの明細数が最大10明細であると決めうち、伝票ヘッダに
伝票明細1行目, 伝票明細2行目, ･･･, 伝票明細10行目 と子へのポインタを
持たせてしまうのだ。これは RDB の設計としては明らかに誤りである。
正規化されていないために、商品A を購入している伝票を検索することが
できなくなってしまうのだから。
しかし、この発想を頭ごなしに否定してはいけない。この発想こそ直接的モデル化なのである。
発想自体は非常に分かりやすく直感的なものである。ただ、RDB においてはスキーマで
表現できないために、「誤り」として否定せざるを得ないだけのことである。このルーキーの
設計を馬鹿にする前に、この発想を直接的にモデル化できない RDB の制限についても
考えてみてもらいたい。RDB がモデル化において完全ではないことが次第に見えてくる。
162 ：NAME IS NULL：04/08/25 22:01 ID:???
まだ RDB の問題を理解できていないだろうと思う。
もうひとつ例題を示そう。
私、山田太郎には複数の子供がいる。さて、山田太郎の子供を探してきて欲しい。
この世界の住人には同名の人は存在しない。RDB に慣れ親しんだ人達は、迷わず、
select 名前 from 住人 where 父親の名前 = '山田太郎' と書くだろう。
間違ってない。結果は正しい。しかし、あなたは、この正しい結果を得るために
信じられないほどの労力を使ったのだ。信じられない？ 簡単な作業だったって？
そんなことはない。自分自身が DBMS になったつもりで上記のクエリを噛み砕いて
実行してみて欲しい。あなたは、世界中の住人を訪ねて周り、「あなたの父親は
山田太郎ですか？」と尋ねなければならなかったのだ。これは、山田太郎の子供を
探すために、世界の住人すべてを走査しなければならないことを意味している。
もちろん、実際のデータベース実装では索引が利用されるため、全住人への
物理走査など発生しない。それは分かっている。ここで考えて欲しいのは、
概念としてどうかということだ。たとえ物理走査が発生しなかったとしても、
論理的には全件走査が行われたのである。DBMS は「全部調べた結果、山田太郎を
父親に持つ人達はこのだけです。」と結果を返すのだから。
「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
「そんなことはできない。」と、あなたは笑うだろう。世界中を旅して周ることに
なんのためらいも持たないのに、本人に聞く事はできないという。
滑稽ではないだろうか。これが現在の RDB なのである。
これに気付かない人は多い。索引によって世界中を旅して周る(のと同じ結果を得る)
など、あっという間にできてしまうからだ。時間はまったくかからない。
時間はかからないけど、世界中を旅していることは理解して欲しい。
もうひとつ例題を示そう。
私、山田太郎には複数の子供がいる。さて、山田太郎の子供を探してきて欲しい。
この世界の住人には同名の人は存在しない。RDB に慣れ親しんだ人達は、迷わず、
select 名前 from 住人 where 父親の名前 = '山田太郎' と書くだろう。
間違ってない。結果は正しい。しかし、あなたは、この正しい結果を得るために
信じられないほどの労力を使ったのだ。信じられない？ 簡単な作業だったって？
そんなことはない。自分自身が DBMS になったつもりで上記のクエリを噛み砕いて
実行してみて欲しい。あなたは、世界中の住人を訪ねて周り、「あなたの父親は
山田太郎ですか？」と尋ねなければならなかったのだ。これは、山田太郎の子供を
探すために、世界の住人すべてを走査しなければならないことを意味している。
もちろん、実際のデータベース実装では索引が利用されるため、全住人への
物理走査など発生しない。それは分かっている。ここで考えて欲しいのは、
概念としてどうかということだ。たとえ物理走査が発生しなかったとしても、
論理的には全件走査が行われたのである。DBMS は「全部調べた結果、山田太郎を
父親に持つ人達はこのだけです。」と結果を返すのだから。
「山田太郎さんに直接、子供達の名前を聞いたらどうですか？」とルーキーが言う。
「そんなことはできない。」と、あなたは笑うだろう。世界中を旅して周ることに
なんのためらいも持たないのに、本人に聞く事はできないという。
滑稽ではないだろうか。これが現在の RDB なのである。
これに気付かない人は多い。索引によって世界中を旅して周る(のと同じ結果を得る)
など、あっという間にできてしまうからだ。時間はまったくかからない。
時間はかからないけど、世界中を旅していることは理解して欲しい。
163 ：NAME IS NULL：04/08/25 22:26 ID:???
>>161
> "伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
なぜでしょう？
伝票番号は明細にだけ存在して、ヘッダには存在しないということでしょうか？
良く理解できないんでどんなデータ構造と参照処理をを想定しているのか、も
うちょっと詳しく教えてもらえませんか？
> "伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
なぜでしょう？
伝票番号は明細にだけ存在して、ヘッダには存在しないということでしょうか？
良く理解できないんでどんなデータ構造と参照処理をを想定しているのか、も
うちょっと詳しく教えてもらえませんか？
164 ：NAME IS NULL：04/08/25 22:27 ID:???
165 ：NAME IS NULL：04/08/25 22:58 ID:???
166 ：NAME IS NULL：04/08/25 23:29 ID:???
>>163
もちろん記述としては、"伝票ヘッダ left outer join 伝票明細" と
書くこともできる。しかし、この記述は外部キー定義に則していない。
伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
>>164
ここでは、山田太郎をポイントする方法を問題とはしていない。
OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
たとえば、横浜市在住の40歳男性にちゃんねらDB板常駐という条件で、
山田太郎が見つかったというストーリーにしたら、満足するだろうか？
とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
>>165
RDB ではモデル化が直接的でなくトリッキーな方法で実現しないといけないことがある、
というのが現在の RDB の問題である。これは、実装技術により速度的にはなんの問題もない。
だが、概念としての難解さを抱えているのである。
select 名前 from 住人 where 父親の名前 = '山田太郎'
もう一度、これを見て欲しい。実装や速度の話をしているのではない。
「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
「山田太郎の子供を探す」という命題が「住人すべての中から山田太郎を父親に
持つ人を抽出する」としか記述できないのである。これは本質を、RDB の性質に
合わせて書き換えているということであり、可読性の低下をもたらしている、とも言える。
この RDB の性質に合わせた問い合わせの書き換えについては、可読性の低下だけでなく
誤った結果を得てしまうというミスにつながることも少なくない。このミスの発生については
また改めて名寄せに類似した問題で説明することにしよう。
もちろん記述としては、"伝票ヘッダ left outer join 伝票明細" と
書くこともできる。しかし、この記述は外部キー定義に則していない。
伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
>>164
ここでは、山田太郎をポイントする方法を問題とはしていない。
OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
たとえば、横浜市在住の40歳男性にちゃんねらDB板常駐という条件で、
山田太郎が見つかったというストーリーにしたら、満足するだろうか？
とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
>>165
RDB ではモデル化が直接的でなくトリッキーな方法で実現しないといけないことがある、
というのが現在の RDB の問題である。これは、実装技術により速度的にはなんの問題もない。
だが、概念としての難解さを抱えているのである。
select 名前 from 住人 where 父親の名前 = '山田太郎'
もう一度、これを見て欲しい。実装や速度の話をしているのではない。
「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
「山田太郎の子供を探す」という命題が「住人すべての中から山田太郎を父親に
持つ人を抽出する」としか記述できないのである。これは本質を、RDB の性質に
合わせて書き換えているということであり、可読性の低下をもたらしている、とも言える。
この RDB の性質に合わせた問い合わせの書き換えについては、可読性の低下だけでなく
誤った結果を得てしまうというミスにつながることも少なくない。このミスの発生については
また改めて名寄せに類似した問題で説明することにしよう。
167 ：NAME IS NULL：04/08/26 00:00 ID:???
>>166
> しかし、この記述は外部キー定義に則していない。
なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
操作における参照方向を定義したものじゃないと思ってたけど。
「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
それは参照方向の定義だ」という主張でしょうか？
> 伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
> 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
それで良いと思うけど。OIDならそれを回避できるわけじゃないですよね？
OIDが物理アドレスに簡単に変換できるかどうかというのはまさしく「実装」
の問題ですよね？
> >>164
> OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
変だと思うけど。
> とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
よい、ということでしょうか？
> しかし、この記述は外部キー定義に則していない。
なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
操作における参照方向を定義したものじゃないと思ってたけど。
「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
それは参照方向の定義だ」という主張でしょうか？
> 伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
> 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
それで良いと思うけど。OIDならそれを回避できるわけじゃないですよね？
OIDが物理アドレスに簡単に変換できるかどうかというのはまさしく「実装」
の問題ですよね？
> >>164
> OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
変だと思うけど。
> とにかく、山田太郎は見つかった。そこから子供を探したいということだ。
つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
よい、ということでしょうか？
168 ：NAME IS NULL：04/08/26 00:25 ID:???
>>165
>実装や速度の話をしているのではない。
>「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
>これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
そうなの？実装されたプログラムの速度が問題なのかとおもってた…
速度が問題じゃないなら、あなたがやっかいさを指摘してるのは「関係代数」なのか。
そこまでくると話が発散しそうだな。たとえば行列演算や基礎物理が理解できないやつに
ポリゴン使った3Dゲームのプログラム任せられないのと一緒で、
関係代数のエッセンスをつかめないやつにRDB使うプログラム任せるなってことに
なってしまう。
それとも、ORマッピングなんて所詮ムリヤリな話だからオブジェクト指向の
大事なメリットを損ねるのよ、だからプログラムをOOでやるなら
DBもOOでやれよって話？
>実装や速度の話をしているのではない。
>「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
>これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。
そうなの？実装されたプログラムの速度が問題なのかとおもってた…
速度が問題じゃないなら、あなたがやっかいさを指摘してるのは「関係代数」なのか。
そこまでくると話が発散しそうだな。たとえば行列演算や基礎物理が理解できないやつに
ポリゴン使った3Dゲームのプログラム任せられないのと一緒で、
関係代数のエッセンスをつかめないやつにRDB使うプログラム任せるなってことに
なってしまう。
それとも、ORマッピングなんて所詮ムリヤリな話だからオブジェクト指向の
大事なメリットを損ねるのよ、だからプログラムをOOでやるなら
DBもOOでやれよって話？
169 ：NAME IS NULL：04/08/26 00:27 ID:???
まちがえた >>166 ね。
170 ：NAME IS NULL：04/08/26 00:45 ID:???
> なんで？外部キー定義って表同士の関係（状態）を表しているもので、データ
> 操作における参照方向を定義したものじゃないと思ってたけど。
外部キー定義とは、データ走査における(推奨される)参照方向の定義である。
これに従わないものは「辿る(外部参照)」という行為ではなく横断的検索である。
なぜなら、外部キーの性質により順方向の参照は、必ず 1件の結果となるが、
逆方向の参照結果が 1件になることは稀だからである。
> 「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
> それは参照方向の定義だ」という主張でしょうか？
主張するつもりはないが事実としてそうである。伝票明細は商品への外部参照を持つ。
これは、「伝票明細から売り上げた商品を知ることができる」ことを意味する。
商品から無数に存在する伝票明細への参照というのはモデル化として、おかしい。
> > 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
> それで良いと思うけど。
「伝票明細全体から探す」ということに疑問を感じないのであれば、
私は、もうこれ以上あなたに説明するだけの言葉を持っていないということだと思う。
> だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
> 変だと思うけど。
> つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
> よい、ということでしょうか？
申し訳ないが、これらの質問の意味・意図も理解できなかった。
あなたは何をしたいのか？
> 操作における参照方向を定義したものじゃないと思ってたけど。
外部キー定義とは、データ走査における(推奨される)参照方向の定義である。
これに従わないものは「辿る(外部参照)」という行為ではなく横断的検索である。
なぜなら、外部キーの性質により順方向の参照は、必ず 1件の結果となるが、
逆方向の参照結果が 1件になることは稀だからである。
> 「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
> それは参照方向の定義だ」という主張でしょうか？
主張するつもりはないが事実としてそうである。伝票明細は商品への外部参照を持つ。
これは、「伝票明細から売り上げた商品を知ることができる」ことを意味する。
商品から無数に存在する伝票明細への参照というのはモデル化として、おかしい。
> > 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
> それで良いと思うけど。
「伝票明細全体から探す」ということに疑問を感じないのであれば、
私は、もうこれ以上あなたに説明するだけの言葉を持っていないということだと思う。
> だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
> 変だと思うけど。
> つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
> よい、ということでしょうか？
申し訳ないが、これらの質問の意味・意図も理解できなかった。
あなたは何をしたいのか？
171 ：NAME IS NULL：04/08/26 00:59 ID:???
> DBもOOでやれよって話？
これだけは否定しておいたほうがいいだろう。私はモデル化の制限について話し、
これらが実装の問題でないことを説明してきた。だが･･･今までの私の説明と矛盾するようだが、
もっとも重要なのが「実装」なのである。なぜなら、実装を差し置いて(理想的なモデル化論だけで)
システムを組み上げることはできないからである。
つまり実際に使用できる実装を考えた場合、現時点では RDB を選択するのが
もっとも良いと私自身考えている。ハンドリングが Java などの OOP であったとしても
バックエンドには、現時点で RDB を選択すべきなのである。私は OODB を推したりはしない。
ただ、いまの RDB が 100年続くとは思って欲しくない。私が指摘したように
うまくモデル化できない事象もたくさんある。これらを真面目に考えていくことは
RDB のブレークスルーになるかもしれないのだ。
これだけは否定しておいたほうがいいだろう。私はモデル化の制限について話し、
これらが実装の問題でないことを説明してきた。だが･･･今までの私の説明と矛盾するようだが、
もっとも重要なのが「実装」なのである。なぜなら、実装を差し置いて(理想的なモデル化論だけで)
システムを組み上げることはできないからである。
つまり実際に使用できる実装を考えた場合、現時点では RDB を選択するのが
もっとも良いと私自身考えている。ハンドリングが Java などの OOP であったとしても
バックエンドには、現時点で RDB を選択すべきなのである。私は OODB を推したりはしない。
ただ、いまの RDB が 100年続くとは思って欲しくない。私が指摘したように
うまくモデル化できない事象もたくさんある。これらを真面目に考えていくことは
RDB のブレークスルーになるかもしれないのだ。
172 ：NAME IS NULL：04/08/26 01:13 ID:???
>>170
私は167ではないけど、まぁもちついて。
167が言ってるのは…DBMSのメリットのひとつ
[特定のデータ操作からデータの内部構造を独立させることができ、
その独立性によって仕様変更に対する柔軟性が向上したり、
他のクエリに対しても同じような速度でアクセスできるという期待を持てる]
をあげてる。
特定の操作に対する最適化は、それはそれでアリだけど、
それを持ち出してきてRDB、というか関係代数が問題を含んでいる
というのはちと飛躍かと。
あと、１：Nの例を挙げてるけど、現実世界がN：Mになっててそれを
率直にモデリングしたい場合もあるわけで。関係代数のメリットって
それを中立的に表現できることじゃないの？
それから気になったこと。
やろうと思えば親１：子N関係でも親から子へ、子の数に関係なくリンク張れるがな。
C言語なんかではN分木を、「長男と弟へのリンク」の２分木として実装するでしょ。
それと一緒。伝票ヘッダは商品１へのリンクだけ持ってて、商品１が
商品２へのリンクを持ってればすむ。
あなたならディレクトリ構造みたいな木をどうやってコーディングするのさ？
そんでそれは、関係代数マンセーな視点からは「最適化に含まれるので
別議論である」ってこと。
私は167ではないけど、まぁもちついて。
167が言ってるのは…DBMSのメリットのひとつ
[特定のデータ操作からデータの内部構造を独立させることができ、
その独立性によって仕様変更に対する柔軟性が向上したり、
他のクエリに対しても同じような速度でアクセスできるという期待を持てる]
をあげてる。
特定の操作に対する最適化は、それはそれでアリだけど、
それを持ち出してきてRDB、というか関係代数が問題を含んでいる
というのはちと飛躍かと。
あと、１：Nの例を挙げてるけど、現実世界がN：Mになっててそれを
率直にモデリングしたい場合もあるわけで。関係代数のメリットって
それを中立的に表現できることじゃないの？
それから気になったこと。
やろうと思えば親１：子N関係でも親から子へ、子の数に関係なくリンク張れるがな。
C言語なんかではN分木を、「長男と弟へのリンク」の２分木として実装するでしょ。
それと一緒。伝票ヘッダは商品１へのリンクだけ持ってて、商品１が
商品２へのリンクを持ってればすむ。
あなたならディレクトリ構造みたいな木をどうやってコーディングするのさ？
そんでそれは、関係代数マンセーな視点からは「最適化に含まれるので
別議論である」ってこと。
173 ：NAME IS NULL：04/08/26 07:12 ID:???
おはよう、諸君。
あなたたちは、まだ理解が追いついていないようだ。
もうちょっと説明してあげたいこともあったのだが、的外れな質問で
話が遮られるばかりなので、ここでの説明はこれで打ち止めとしよう。
非常に残念なことである。
あなたたちには、これからももっとがんばってもらいたいものである。
あなたたちは、まだ理解が追いついていないようだ。
もうちょっと説明してあげたいこともあったのだが、的外れな質問で
話が遮られるばかりなので、ここでの説明はこれで打ち止めとしよう。
非常に残念なことである。
あなたたちには、これからももっとがんばってもらいたいものである。
174 ：NAME IS NULL：04/08/26 16:55 ID:???
>>173
あまり論点が明確化されてなくて探りを入れることになったので、質問が的を
はずしていたかもしれないのはしょうがないですね。
＃全くの他人とは、あまり議論されたことが無いのかな？
私は結局論点にしたいのがモデルなのか、DB利用者にとっての実装か、DBMS自
体の実装か、利用する上でのシンタックスなのか分からずじまいでした。
もう止めるということなので残念です。どなたか>>170にあった「外部キー定
義とは、データ走査における(推奨される)参照方向の定義」というのが分かる
Webサイトか何か知りませんか？
＃もう今の環境じゃDB関連の書籍が手元に無い、、、
私の頭の中じゃ、外部キー定義はレコードが参照して整合性を保つためのもの
で、アプリがその参照を参考にしながら逆方向に辿るのは全然OKだと理解して
た。
あまり論点が明確化されてなくて探りを入れることになったので、質問が的を
はずしていたかもしれないのはしょうがないですね。
＃全くの他人とは、あまり議論されたことが無いのかな？
私は結局論点にしたいのがモデルなのか、DB利用者にとっての実装か、DBMS自
体の実装か、利用する上でのシンタックスなのか分からずじまいでした。
もう止めるということなので残念です。どなたか>>170にあった「外部キー定
義とは、データ走査における(推奨される)参照方向の定義」というのが分かる
Webサイトか何か知りませんか？
＃もう今の環境じゃDB関連の書籍が手元に無い、、、
私の頭の中じゃ、外部キー定義はレコードが参照して整合性を保つためのもの
で、アプリがその参照を参考にしながら逆方向に辿るのは全然OKだと理解して
た。
175 ：NAME IS NULL：04/08/26 19:31 ID:ps/wA+nf
外部参照制約に方向はあるよね。
逆向きに使っちゃいけないのかどうかは知らんけど。
スキーマとして依存関係を記しているというのもうなずける。
話の意味は良くわかんないんだけど、読み物として面白いから
山田太郎先生には返ってきて欲しいぞ。
逆向きに使っちゃいけないのかどうかは知らんけど。
スキーマとして依存関係を記しているというのもうなずける。
話の意味は良くわかんないんだけど、読み物として面白いから
山田太郎先生には返ってきて欲しいぞ。
176 ：NAME IS NULL：04/08/26 22:28 ID:???
OODBにしてもXMLDBにしても、そういう一風変わったモノは
DQNに取り憑かれ易いよなぁ。
DQNに取り憑かれ易いよなぁ。
177 ：NAME IS NULL：04/09/01 00:39 ID:???
あそれ〜♪
D どんな
Q クエリも
N ぬるぽで返す〜
ときたもんだ
∧＿∧
（ ´∀｀） ＜ぬるぽ
D どんな
Q クエリも
N ぬるぽで返す〜
ときたもんだ
∧＿∧
（ ´∀｀） ＜ぬるぽ
178 ：U ◆CZtFsGiu0c ：04/09/03 12:44 ID:???
最近知ったのですが、ObjectCacheってバックエンドがRDBでも使えるのですね。
分散環境で高速参照が必要なところで使ってみると面白いかも。
分散環境で高速参照が必要なところで使ってみると面白いかも。
179 ：NAME IS NULL：04/09/21 23:58:35 ID:???
遅レスだが
>>178 は @it の記事のことですかな？
私はいまODB勉強中なのですが、
確かに面白いかも…
しかし、ううむ…。あの記事、なんか論調として
・RDBを扱える技術者は豊富
・RDBは壊れたときのリカバリなど実績がある
・間にはさむキャッシュとしてObjectCacheをつかうと速くてｳﾏｰ
というように読めたのだけど、それって、
RDBでスピードが出なかったときの
最適化の選択肢なのかな？いやまてよ、
ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
ObjectCache使ったアプリ書いたひといる？
アプリの書き方変わらんの？
>>178 は @it の記事のことですかな？
私はいまODB勉強中なのですが、
確かに面白いかも…
しかし、ううむ…。あの記事、なんか論調として
・RDBを扱える技術者は豊富
・RDBは壊れたときのリカバリなど実績がある
・間にはさむキャッシュとしてObjectCacheをつかうと速くてｳﾏｰ
というように読めたのだけど、それって、
RDBでスピードが出なかったときの
最適化の選択肢なのかな？いやまてよ、
ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
ObjectCache使ったアプリ書いたひといる？
アプリの書き方変わらんの？
180 ：NAME IS NULL：04/09/22 06:52:16 ID:???
最近のシステムではRDBアクセスをEJBで隠蔽しているものが結構あると認識していますが、
これって、EJB-RDBひとまとめにしてDBと考えると、
「EJB+RDB=OODB!! カモンOODB!!」
などと思うのですよ。
本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、
データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
何かないでつか。
これって、EJB-RDBひとまとめにしてDBと考えると、
「EJB+RDB=OODB!! カモンOODB!!」
などと思うのですよ。
本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、
データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
何かないでつか。
181 ：NAME IS NULL：04/09/22 13:24:32 ID:???
age
182 ：NAME IS NULL：04/09/22 14:45:41 ID:???
>>180
> これって、EJB-RDBひとまとめにしてDBと考えると、
> 「EJB+RDB=OODB!! カモンOODB!!」
> などと思うのですよ。
RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
ないでしょうか。
> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
> 何かないでつか。
MATISSEが多少近いかもしれません。meta-schemaをいじれるようになっている
らしいので。
しかし、ユーザに提供しているインタフェースと、DBMS内のモデル・検索処理・
トランザクション管理・排他制御・ディスクページ内レイアウト・ロギングが
密接に関連しているので、完全にフリーにするのは難しいと思います。
RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
合には大抵ライブラリやラッパーをかぶせて実現しています。
無理やり実現しようとすると結局ファイルシステムと大差ないものになってし
まう気がします。
> これって、EJB-RDBひとまとめにしてDBと考えると、
> 「EJB+RDB=OODB!! カモンOODB!!」
> などと思うのですよ。
RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
ないでしょうか。
> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
> 何かないでつか。
MATISSEが多少近いかもしれません。meta-schemaをいじれるようになっている
らしいので。
しかし、ユーザに提供しているインタフェースと、DBMS内のモデル・検索処理・
トランザクション管理・排他制御・ディスクページ内レイアウト・ロギングが
密接に関連しているので、完全にフリーにするのは難しいと思います。
RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
合には大抵ライブラリやラッパーをかぶせて実現しています。
無理やり実現しようとすると結局ファイルシステムと大差ないものになってし
まう気がします。
>>182
レスどうもです。
うーん、考えがまとまってないので少しだけ。
>RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
>する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
>が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
>ないでしょうか。
・・・中略・・・
>RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
>合には大抵ライブラリやラッパーをかぶせて実現しています。
ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
実のところ、既存のoodbは適当な記事に書かれている程度しか知りませんが、
オブジェクト指向のメリットの一つは、データモデルをカプセル化できること
の筈。なら、そのようなDBがあればべんりかな、と。裏側で動いているRDB
のデータモデルも、裏側で検索やっているBLAST*も隠して、同じように／横断
的にアクセスできるとけっこう有り難い・・・。
*blast うちらはcgiでやることが多いのですよ、これ。以下参考；
http://www.ddbj.nig.ac.jp/search/archives/homology_doc-j.html
レスどうもです。
うーん、考えがまとまってないので少しだけ。
>RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
>する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
>が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
>ないでしょうか。
・・・中略・・・
>RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
>合には大抵ライブラリやラッパーをかぶせて実現しています。
ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
実のところ、既存のoodbは適当な記事に書かれている程度しか知りませんが、
オブジェクト指向のメリットの一つは、データモデルをカプセル化できること
の筈。なら、そのようなDBがあればべんりかな、と。裏側で動いているRDB
のデータモデルも、裏側で検索やっているBLAST*も隠して、同じように／横断
的にアクセスできるとけっこう有り難い・・・。
*blast うちらはcgiでやることが多いのですよ、これ。以下参考；
http://www.ddbj.nig.ac.jp/search/archives/homology_doc-j.html
184 ：NAME IS NULL：04/09/23 14:15:13 ID:???
185 ：U ◆CZtFsGiu0c ：04/09/23 14:30:48 ID:???
>>179
>@it の記事のことですかな？
そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック
エンドに使えるとは知らずスルーしていました。
>ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。
ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで
O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー
マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決
できるんじゃないかな、と思います。
>@it の記事のことですかな？
そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック
エンドに使えるとは知らずスルーしていました。
>ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの？
と、なぞが深まりますた。
まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。
ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで
O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー
マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決
できるんじゃないかな、と思います。
187 ：NAME IS NULL：04/09/24 17:47:46 ID:???
>>183
EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。
> ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
> oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
もともとDBMSの類はデータを公開して共有しよう、というところから生まれて
いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま
ま当てはまらないところもあると思います。
カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、
いったんDBに格納した過去のデータは簡単には変更できないという違いもあり
ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど)
アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
利かもしれません。
アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、
・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース
をどうやって定義するのか。
・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部
分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。
辺りが悩ましそうです。考察するのは面白そうだけど
パッケージや製品として世の中に出す場合には、システム非依存にしなければ
ならないところも難しい点だと思います。
逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。
(それも特定の業務「モデル」に縛られることにはなるけど)
＃勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな？SAPもそうだっけ？
EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。
> ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
> oo的にはInterfaceが一緒であればいいかな、と思ったのですが。
もともとDBMSの類はデータを公開して共有しよう、というところから生まれて
いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま
ま当てはまらないところもあると思います。
カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、
いったんDBに格納した過去のデータは簡単には変更できないという違いもあり
ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど)
アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
利かもしれません。
アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、
・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース
をどうやって定義するのか。
・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部
分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。
辺りが悩ましそうです。考察するのは面白そうだけど
パッケージや製品として世の中に出す場合には、システム非依存にしなければ
ならないところも難しい点だと思います。
逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。
(それも特定の業務「モデル」に縛られることにはなるけど)
＃勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな？SAPもそうだっけ？
あう。凄く誤解させてしまったかも。スマソ。
>>187
>アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
>えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
>利かもしれません。
入れ替える、というのが不適切な表現だったようです。
想定している応用はこんな感じです。
1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。
2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。
3.xmlなグラフデータも検索したい。
4.検索結果をオブジェクトとして受け取りたい。
ですので、入れ替えるというよりは組み合わせて使うような。
それだとデータモデル横断的な検索とかできないから何かないか、
というのが180の後半です。
やっぱり
182>ライブラリやラッパーをかぶせて実現
とかObjectCache'とかじゃないと余計悩ましそうですね。
>>187
>アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
>えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
>利かもしれません。
入れ替える、というのが不適切な表現だったようです。
想定している応用はこんな感じです。
1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。
2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。
3.xmlなグラフデータも検索したい。
4.検索結果をオブジェクトとして受け取りたい。
ですので、入れ替えるというよりは組み合わせて使うような。
それだとデータモデル横断的な検索とかできないから何かないか、
というのが180の後半です。
やっぱり
182>ライブラリやラッパーをかぶせて実現
とかObjectCache'とかじゃないと余計悩ましそうですね。
189 ：NAME IS NULL：04/09/26 11:38:40 ID:K2xHeQ+O
とりあえず現在ObjectStoreを使っているけど、全然メリットを感じない。
クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ
ならないんじゃ実運用に耐えない。
ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
またRDBであれば、他システムとの連携が簡単（ODBC,EAIなど）だが、インタフェースが
独自のODBではそれも難しい。
ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や
保守運用時には全然メリットを感じない。
ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
分散キャッシュでのスケールアウトもOracleのRACの方がまし。
ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは
全く感じられない。
クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ
ならないんじゃ実運用に耐えない。
ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
またRDBであれば、他システムとの連携が簡単（ODBC,EAIなど）だが、インタフェースが
独自のODBではそれも難しい。
ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や
保守運用時には全然メリットを感じない。
ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
分散キャッシュでのスケールアウトもOracleのRACの方がまし。
ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは
全く感じられない。
190 ：U ◆CZtFsGiu0c ：04/09/26 19:33:12 ID:???
>>189
(今までの書き込みを見てもらえばわかるけど)大半は同意。
>ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
>ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために
クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では
OODBを積極的に使うほどのメリットには思えないけどね。
>しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
クラスタへの配置とか?
(今までの書き込みを見てもらえばわかるけど)大半は同意。
>ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのＲＤＢでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。
サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
>ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。
いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために
クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では
OODBを積極的に使うほどのメリットには思えないけどね。
>しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。
キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
クラスタへの配置とか?
191 ：NAME IS NULL：04/09/26 21:33:13 ID:K2xHeQ+O
>サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
>メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
特に最近はＤＢサーバ上のストアドが高級言語になりつつあるから、余計ＯＤＢの
メリットが少なくなる。
ＣＰＵ技術が、これからマルチチップ、マルチスレッド＋仮想化進むので、
わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、
運用保守費が増加するだけと思います。
>キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
>クラスタへの配置とか?
クライアントキャッシュのサイズなどです。
確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。
キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。
ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、
それはRACでのスケールアウトでも達成可能。
でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。
個人的には、SQLServer2005のようなストアドの高級言語化の方が、
ODBよりも良いと思われる。
ChacheのようなアプローチもObjectStoreよりかは良いですね。
いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より
値検索の方が多いので、ODBの出番はない。
>メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?
クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
特に最近はＤＢサーバ上のストアドが高級言語になりつつあるから、余計ＯＤＢの
メリットが少なくなる。
ＣＰＵ技術が、これからマルチチップ、マルチスレッド＋仮想化進むので、
わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、
運用保守費が増加するだけと思います。
>キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
>クラスタへの配置とか?
クライアントキャッシュのサイズなどです。
確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。
キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。
ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、
それはRACでのスケールアウトでも達成可能。
でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。
個人的には、SQLServer2005のようなストアドの高級言語化の方が、
ODBよりも良いと思われる。
ChacheのようなアプローチもObjectStoreよりかは良いですね。
いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より
値検索の方が多いので、ODBの出番はない。
192 ：NAME IS NULL：04/09/27 17:56:40 ID:???
>>188
> それだとデータモデル横断的な検索とかできないから何かないか、
> というのが180の後半です。
なるほど。
昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい
だけど、頓挫したのか普及しなかったのか、、、
今はそれ以上にいろんな検索がありえるし。
全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、
後はアプリケーションでがんばってね、とか。
結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。
・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定
・インタフェースはOODBを参考に
・引数等で各バックエンド固有の機能を記述することは極力避ける
というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事
はしていないなw
.NETとかは一応この方向を目指してるんだっけ？
> それだとデータモデル横断的な検索とかできないから何かないか、
> というのが180の後半です。
なるほど。
昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい
だけど、頓挫したのか普及しなかったのか、、、
今はそれ以上にいろんな検索がありえるし。
全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、
後はアプリケーションでがんばってね、とか。
結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。
・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定
・インタフェースはOODBを参考に
・引数等で各バックエンド固有の機能を記述することは極力避ける
というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事
はしていないなw
.NETとかは一応この方向を目指してるんだっけ？
193 ：NAME IS NULL：04/09/27 18:18:48 ID:???
>>191
ほぼ全面的に同意ですが、
> クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
> ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思
えないです。
また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの
なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。
OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ
に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛
いですね。
HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し
かないですし。
ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作
したんだろう？
ほぼ全面的に同意ですが、
> クライアント上のキャッシュと言っても、実質ＡＰサーバ上でのキャッシュなので、
> ＡＰサーバとＤＢサーバが統合されてしまえば、全く問題なし。
性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思
えないです。
また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの
なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。
OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ
に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛
いですね。
HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し
かないですし。
ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作
したんだろう？
194 ：NAME IS NULL：04/09/27 22:21:11 ID:???
オブジェクト指向でシステムを設計すると、多態性のあるオブジェクト群をひ
とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく
出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする
と１インスタンス＝１レコード といった単純な格納の仕方が通用しなくなる
ので、かなり頭をひねらなくてはならなくなると思います。
そういったことを考えると、ODBといったものの方が自然に扱えていいと思う
のですがいかがですか。
とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく
出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする
と１インスタンス＝１レコード といった単純な格納の仕方が通用しなくなる
ので、かなり頭をひねらなくてはならなくなると思います。
そういったことを考えると、ODBといったものの方が自然に扱えていいと思う
のですがいかがですか。
195 ：NAME IS NULL：04/09/28 13:23:11 ID:???
>>194
ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ
クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に
そうだし、他のOODBもそれを志向しています。
そのためプログラミングは便利になるかもしれないけど、システムを稼動させ
たときの運用などにしわ寄せがよってしまいます。
どちらがクリティカルかといえば、動かしたときの方だと思います。
ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ
クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に
そうだし、他のOODBもそれを志向しています。
そのためプログラミングは便利になるかもしれないけど、システムを稼動させ
たときの運用などにしわ寄せがよってしまいます。
どちらがクリティカルかといえば、動かしたときの方だと思います。
196 ：NAME IS NULL：04/09/28 15:32:32 ID:???
>>195 うーん、そうなんですか。
- オブジェクトをアプリケーションから透過的に永続化したい
というニーズと
- オブジェクト指向設計に即したデータストアのインフラが欲しい
というニーズは似て非なるものですよね。
現行の製品はもしかすると前者からスタートしているのでしょうか。
だとすればあまり魅力を感じません。
むしろ欲しいのは後者です。今後に期待したいですね。
- オブジェクトをアプリケーションから透過的に永続化したい
というニーズと
- オブジェクト指向設計に即したデータストアのインフラが欲しい
というニーズは似て非なるものですよね。
現行の製品はもしかすると前者からスタートしているのでしょうか。
だとすればあまり魅力を感じません。
むしろ欲しいのは後者です。今後に期待したいですね。
197 ：NAME IS NULL：04/09/28 17:25:43 ID:???
>>196
ZopeのZODBなんかは、前のやつそのものって感じですね。
ZopeのZODBなんかは、前のやつそのものって感じですね。
198 ：NAME IS NULL：04/09/28 18:00:58 ID:???
>>197
Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの
ように扱える反面、Pythonからしかアクセスできないみたいですね。
データベースに格納したオブジェクトが、例えばCORBAのような
汎用のインターフェースを通じてリモートオブジェクトとして
アクセスできるような製品はないんでしょうか。
Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの
ように扱える反面、Pythonからしかアクセスできないみたいですね。
データベースに格納したオブジェクトが、例えばCORBAのような
汎用のインターフェースを通じてリモートオブジェクトとして
アクセスできるような製品はないんでしょうか。
199 ：NAME IS NULL：04/09/28 19:30:14 ID:???
>>198
CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し
てCORBA側が対応したのかな？
だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく
知りません。
そもそもPOS自体が企画倒れになったらしいから、あまり（CORBAとしては)力
を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか
な。分散トランザクションもややこしいし。
CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し
てCORBA側が対応したのかな？
だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく
知りません。
そもそもPOS自体が企画倒れになったらしいから、あまり（CORBAとしては)力
を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか
な。分散トランザクションもややこしいし。
200 ：NAME IS NULL：04/10/12 15:42:35 ID:???
>>199
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。
POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。
POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。