>>118
> では、その保存する形がＲＤＢのテーブルであろうと、オブジェクトまるごとであろうと、その点には関係ないですよね。

ただ保存するだけなら何でもよいです。それこそCSVでもXMLでもシリアライズでも。
＃そしてその要求は言語から来るものではありません。

後で利用することを考慮して、言語オブジェクト丸ごとでは問題が起こるとい
うことを上で書きました。(インタフェース・シンタックスとしてSQLが褒められ
たもんじゃないということは更に上でも書いてます)

> 開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
> それからコンパイルされ、普通の実行形式のプログラムに変換されます。

それは分かりますが、どう実行されるかはあまり考えないのでしょうか。コン
パイルするためにコードを書いてるんじゃなくて、実行するために書いてるん
でしょ?

SQLをコードの中に埋め込んだということは、

・その部分が実行されるときはネットワークを介してサーバへリクエストが飛ぶ
・サーバ内で何かが実行される
・その結果が自分のコードの中へ返ってくる

ということがまず考えられて、さらに

・そのサーバへは別のプログラムもリクエストを出している
・今のプロジェクトで開発したプログラムじゃなくて、例えばAccessを使った管理ツールもリクエストを飛ばしている

というようにシステム構成を考えていけば、>>113で挙げたような問題点にぶ
ち当たると思うんですが。

例えばHTTPサーバには複数のクライアントからリクエストが来ていますが、
・HTTPサーバをJavaで作った
・WebブラウザもJavaで作った
とここまでは良いとして、
・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
なんて考えないでしょ?