OODB - オブジェクト指向データベース (311ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
113(4): [age] 04/07/27 16:41 ID:??? AAS
>>107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。
> 外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。
開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
> これはOODBの場合って話ですか？ なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
省29
115(2): U ◆CZtFsGiu0c 04/07/27 19:23 ID:??? AAS
>>113
>１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。
>２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。
これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
省22
118(2): 04/07/28 22:19 ID:??? AAS
>>113
> まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
> 象は違わないし、保存する必要性も変わらないと思います。
では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
>> esql/c でもpro*cでもいいですが、プリプロセッサです。
>
>開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?
組込型言語とでもいうんですかね。忘れました。
開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
それからコンパイルされ、普通の実行形式のプログラムに変換されます。
122(1): [age] 04/07/29 13:41 ID:??? AAS
>>118
> では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。
ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。
＃そしてその要求は言語から来るものではありません。
後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
たもんじゃないということは更に上でも書いてます)
> 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
> それからコンパイルされ、普通の実行形式のプログラムに変換されます。
それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
省17
127(1): 04/07/29 20:37 ID:??? AAS
>>122
> 後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
> うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
> たもんじゃないということは更に上でも書いてます)
では何だったらいいのでしょうか？
> それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
> パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
> でしょ?
聞かれたから答えたのに。ｼｸｼｸ
> というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
省16
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ ｱﾎﾞﾝOFF
ぬこの手 ぬこTOP 1.128s*