OODB - オブジェクト指向データベース (311ﾚｽ)
OODB - オブジェクト指向データベース http://mevius.5ch.net/test/read.cgi/db/1057157392/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
113: NAME IS NULL [age] 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にも制約を受けます。性能チュー ニングのためにページサイズを変更することさえままならない。 コンパイラのバージョンまで制限されそうです。 ＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ ＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。 http://mevius.5ch.net/test/read.cgi/db/1057157392/113
115: U ◆CZtFsGiu0c [sage] 04/07/27 19:23 ID:??? >>113 >１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計 に基づいた過去のデータが入っています。 確かにDBに入れたオブジェクトはアプリケーションに特化したものになり がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。 >２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能 性がある。 これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は 高いと思います。 >>114 >CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー ションのイメージがつかめないんですよね。 CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント 間で同一データを扱っている際に、更新を即時に反映できることです。 通信系システムで採用されている理由も同じでしょうね。 ＃もう一つ共通点としては「データの再利用」や「アドホックな操作」が ＃不要なことも挙げられます >買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの は無いんでしょうか。 ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える とプログラムが異常終了します:-P >この利用例のアーキテクチャはどうなっているでしょうか。 まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。 >個人的には ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う ので、そうであれば合点がいくのですが。 すいません、つながりがよくわかりません。 http://mevius.5ch.net/test/read.cgi/db/1057157392/115
118: NAME IS NULL [sage] 04/07/28 22:19 ID:??? >>113 > まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対 > 象は違わないし、保存する必要性も変わらないと思います。 では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。 >> esql/c でもpro*cでもいいですが、プリプロセッサです。 > >開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ? 組込型言語とでもいうんですかね。忘れました。 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、 それからコンパイルされ、普通の実行形式のプログラムに変換されます。 http://mevius.5ch.net/test/read.cgi/db/1057157392/118
122: NAME IS NULL [age] 04/07/29 13:41 ID:??? >>118 > では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。 ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。 ＃そしてその要求は言語から来るものではありません。 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ たもんじゃないということは更に上でも書いてます) > 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、 > それからコンパイルされ、普通の実行形式のプログラムに変換されます。 それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん でしょ? SQLをコードの中に埋め込んだということは、 ・その部分が実行されるときはネットワークを介してサーバへリクエストが飛ぶ ・サーバ内で何かが実行される ・その結果が自分のコードの中へ返ってくる ということがまず考えられて、さらに ・そのサーバへは別のプログラムもリクエストを出している ・今のプロジェクトで開発したプログラムじゃなくて、例えばAccessを使った管理ツールもリクエストを飛ばしている というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ ち当たると思うんですが。 例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、 ・HTTPサーバをJavaで作った ・WebブラウザもJavaで作った とここまでは良いとして、 ・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。 なんて考えないでしょ? http://mevius.5ch.net/test/read.cgi/db/1057157392/122
127: NAME IS NULL [sage] 04/07/29 20:37 ID:??? >>122 > 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい > うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ > たもんじゃないということは更に上でも書いてます) では何だったらいいのでしょうか？ > それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン > パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん > でしょ? 聞かれたから答えたのに。ｼｸｼｸ > というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ > ち当たると思うんですが。 （１について） 別にRDBでもOODBでも同じ問題だと思います。 （２について） 確かにそうですね。 （３について） そうは思わないです。ただのいちゃもんに聞こえます。 >・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。 >なんて考えないでしょ? 言語依存のOODBじゃなくてWebサービスならOKってことでしょうか？ > 例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、 > ・HTTPサーバをJavaで作った > ・WebブラウザもJavaで作った > とここまでは良いとして、 > ・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。 > なんて考えないでしょ? http://mevius.5ch.net/test/read.cgi/db/1057157392/127
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
ｱﾎﾞﾝOFF
Google検索
Wikipedia
ぬこの手
ぬこTOP
1.139s*