>>107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。

まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。

> 　外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。

開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?

> 　これはOODBの場合って話ですか？　なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。

いくつか考えられますが。

１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。

最初に作った人はハッピーなんでしょうけど。

いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。

２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか？

システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。


３：基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。

思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。

> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。

このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。

＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。