OODB - オブジェクト指向データベース
javaの盛り上がりでOODBに移行していくと思いきや O-Rマッピングかよ! 語りやがれ! 最近のシステムではRDBアクセスをEJBで隠蔽しているものが結構あると認識していますが、 これって、EJB-RDBひとまとめにしてDBと考えると、 「EJB+RDB=OODB!! カモンOODB!!」 などと思うのですよ。 本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、 データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、 何かないでつか。 >>180 > これって、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 >>180 > データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、 フリーって何のことか補足キボンヌ >>179 >@it の記事のことですかな? そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック エンドに使えるとは知らずスルーしていました。 >ObjectCacheかましたらアプリケーションの 書き方変わるんじゃないか… じゃあ最初から使うつもりでないといかんの? と、なぞが深まりますた。 まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。 ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決 できるんじゃないかな、と思います。 >>184 交換可。データモデル等からある程度自由になりたいの。 プラッガブルとか書いた方が良かったかな。 >>183 EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。 > ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。 > oo的にはInterfaceが一緒であればいいかな、と思ったのですが。 もともとDBMSの類はデータを公開して共有しよう、というところから生まれて いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま ま当てはまらないところもあると思います。 カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、 いったんDBに格納した過去のデータは簡単には変更できないという違いもあり ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど) アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替 えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便 利かもしれません。 アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、 ・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース をどうやって定義するのか。 ・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部 分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。 辺りが悩ましそうです。考察するのは面白そうだけど パッケージや製品として世の中に出す場合には、システム非依存にしなければ ならないところも難しい点だと思います。 逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。 (それも特定の業務「モデル」に縛られることにはなるけど) #勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな?SAPもそうだっけ? あう。凄く誤解させてしまったかも。スマソ。 >>187 >アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替 >えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便 >利かもしれません。 入れ替える、というのが不適切な表現だったようです。 想定している応用はこんな感じです。 1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。 2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。 3.xmlなグラフデータも検索したい。 4.検索結果をオブジェクトとして受け取りたい。 ですので、入れ替えるというよりは組み合わせて使うような。 それだとデータモデル横断的な検索とかできないから何かないか、 というのが180の後半です。 やっぱり 182>ライブラリやラッパーをかぶせて実現 とかObjectCache'とかじゃないと余計悩ましそうですね。 とりあえず現在ObjectStoreを使っているけど、全然メリットを感じない。 クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ ならないんじゃ実運用に耐えない。 ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、 高速機関などのRDBでもメモリキャッシュを実現しているので、MRAMやRRAMが いずれ実現する事を考えると少なくともObjectStoreのメリットはない。 またRDBであれば、他システムとの連携が簡単(ODBC,EAIなど)だが、インタフェースが 独自のODBではそれも難しい。 ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や 保守運用時には全然メリットを感じない。 ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが 必要だから工数は全然変わらない。 しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス チューニングが自動化してきたRDBと比べると全くメリットなし。 分散キャッシュでのスケールアウトもOracleのRACの方がまし。 ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは 全く感じられない。 >>189 (今までの書き込みを見てもらえばわかるけど)大半は同意。 >ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、 高速機関などのRDBでもメモリキャッシュを実現しているので、MRAMやRRAMが いずれ実現する事を考えると少なくともObjectStoreのメリットはない。 サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。 メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では? >ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが 必要だから工数は全然変わらない。 いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では OODBを積極的に使うほどのメリットには思えないけどね。 >しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス チューニングが自動化してきたRDBと比べると全くメリットなし。 キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの クラスタへの配置とか? >サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。 >メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では? クライアント上のキャッシュと言っても、実質APサーバ上でのキャッシュなので、 APサーバとDBサーバが統合されてしまえば、全く問題なし。 特に最近はDBサーバ上のストアドが高級言語になりつつあるから、余計ODBの メリットが少なくなる。 CPU技術が、これからマルチチップ、マルチスレッド+仮想化進むので、 わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、 運用保守費が増加するだけと思います。 >キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの >クラスタへの配置とか? クライアントキャッシュのサイズなどです。 確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。 キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。 ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、 それはRACでのスケールアウトでも達成可能。 でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。 個人的には、SQLServer2005のようなストアドの高級言語化の方が、 ODBよりも良いと思われる。 ChacheのようなアプローチもObjectStoreよりかは良いですね。 いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より 値検索の方が多いので、ODBの出番はない。 >>188 > それだとデータモデル横断的な検索とかできないから何かないか、 > というのが180の後半です。 なるほど。 昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい だけど、頓挫したのか普及しなかったのか、、、 今はそれ以上にいろんな検索がありえるし。 全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、 後はアプリケーションでがんばってね、とか。 結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。 ・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定 ・インタフェースはOODBを参考に ・引数等で各バックエンド固有の機能を記述することは極力避ける というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事 はしていないなw .NETとかは一応この方向を目指してるんだっけ? >>191 ほぼ全面的に同意ですが、 > クライアント上のキャッシュと言っても、実質APサーバ上でのキャッシュなので、 > APサーバとDBサーバが統合されてしまえば、全く問題なし。 性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思 えないです。 また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。 OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛 いですね。 HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し かないですし。 ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作 したんだろう? オブジェクト指向でシステムを設計すると、多態性のあるオブジェクト群をひ とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく 出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする と1インスタンス=1レコード といった単純な格納の仕方が通用しなくなる ので、かなり頭をひねらなくてはならなくなると思います。 そういったことを考えると、ODBといったものの方が自然に扱えていいと思う のですがいかがですか。 >>194 ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に そうだし、他のOODBもそれを志向しています。 そのためプログラミングは便利になるかもしれないけど、システムを稼動させ たときの運用などにしわ寄せがよってしまいます。 どちらがクリティカルかといえば、動かしたときの方だと思います。 >>195 うーん、そうなんですか。 - オブジェクトをアプリケーションから透過的に永続化したい というニーズと - オブジェクト指向設計に即したデータストアのインフラが欲しい というニーズは似て非なるものですよね。 現行の製品はもしかすると前者からスタートしているのでしょうか。 だとすればあまり魅力を感じません。 むしろ欲しいのは後者です。今後に期待したいですね。 >>196 ZopeのZODBなんかは、前のやつそのものって感じですね。 >>197 Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの ように扱える反面、Pythonからしかアクセスできないみたいですね。 データベースに格納したオブジェクトが、例えばCORBAのような 汎用のインターフェースを通じてリモートオブジェクトとして アクセスできるような製品はないんでしょうか。 >>198 CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し てCORBA側が対応したのかな? だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく 知りません。 そもそもPOS自体が企画倒れになったらしいから、あまり(CORBAとしては)力 を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか な。分散トランザクションもややこしいし。 >>199 遅レスですみせん。 ODMG, POSという言葉を知らなかったので調べてました。 POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。 CORBA自体が下火だからでしょうか。 >>200 > CORBA自体が下火だからでしょうか。 結局水平分散はコンセプトとしては美しいけど、方式設計や運用設計が難しかっ たんですかね。 だからといってEJBや.NETの世界に行っても、ヘテロジニアスなストレージレ イヤの水平分散・統合が簡単になることもなさそうと思ってるんですけど、実 際どんな感じなんでしょう?>使っている方。 Entity BeanやEJBの分散トランザクション管理機能(DBMSにdispatchするだけ じゃなくて)がここまで進化した、というような話はあるでしょうか? ttp://www.atmarkit.co.jp/fdb/single/01_rfid_database/rfid_database01.html RFID、ECサイトに求められるデータベース性能とは? >バックエンドのRDBMSはそのままに、 >フロントエンドのデータ・キャッシングに「ObjectStore 注」のファミリ製品であるObjectCacheを導入することで、 >Linuxマシン上で稼働する4つのObjectCacheインスタンスにリプレイスでき、コストを大幅に削減できました >同期処理時間は12時間から1分以内に改善され、応答速度も向上しています。 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか? >>202 > 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか? 使っているのはOODBじゃなくて、キャッシュでは? 機能を想像してみると、RDBのデータをどの単位か分からないけれどフロント エンドマシンにキャッシュして、OOPLから透過にアクセスできる、というもの じゃないでしょうか。 RDBMSのデータキャッシュページと連動させていたら結構すごい機能だと思う けど、やってるのかな。 ディスクじゃなくてメモリにすれば、そりゃ速くなるでしょうね。 「同期処理」とか注文処理のトランザクションの内容やタイミングが分からな いから、どの程度キャッシュの賢さが効いているのか分からないけど。もとも との設計がタコだったのかもしれないし。 数年前のシステムを公開しているのだと仮定すると、当時と比べればIAサーバ の性能も上がってコストも安くなってるだろうし、Linuxも最近ようやく使い 物になってきたし。この辺はObjectCacheとは全然関係ないですね。 ところで、ObjectStoreっていつの間にか買収されてたんですね。3年ぐらい前 はXMLブームに乗って「今後はXMLに特化した製品・会社になる」と宣言してい たような気がしたんですが、最近はEC・リアルタイムに特化なんでしょうか。 Cach?を使ってみたいのに、手早くMySQLに逃げてしまう漏れ。 自宅ではMacOSXなので動かん。どうしょ。 >>203 想像のとおりで、このアイデアにはOODBの研究者 ベンチャー(ObjectStoreなど)が興奮したわけですね。 しかし、reading in dababase systemsの編者による解説部分や、 Of Objects and Databases: A Decade of Turmoil by dewittを 読めばわかるが、OODBは、CADなどニッチな市場しか獲得できず、 期待していた市場は、ORDBに取って代わられたということ。 キャッシュコーヒーレンスや、ロックは、callback lockingなど いろいろ工夫したが、典型的なOLTPアプリでは、性能が出ない。 OODBの性能の肝は、キャッシュ制御にあるが、この辺の研究成果はRDBにも適用 できるわけで。 OODBの大きな利点に、ホスト言語と問い合わせ言語間のインピーダンスミスマッチと 複雑なデータ構造を処理できる点にあるが、昨今の流れでは、dewitt氏も指摘したが、 ORマッピングが商用では主流、今後もOODBはニッチな市場しかないじゃないかな。 質問なんですが、OODBに格納されているデータを覗くには、とにもかくにもプログラムインターフェイスを介さないと見れないのでしょうか? OracleのSQL*Plusとか、それこそAccessみたいな感じのビューワってあるんでしょうか? (簡単にデータの格納状態がエビデンスとして見れるツールがないと開発には使えない) まぁ仮にそういうツールがあったとしても、おそらくそういったビューワでオブジェクトを参照できるようにするためには そのオブジェクトがOODB製品が提供する独自のツール表示用interfaceを実装する必要があるとか、 そういう仕組みがあるのでしょうけど。 あと>>32 にも書いてあるが、クロス言語を実現できる製品はあるのでしょうか? 例えばOODBの提供するinterdaceを実装することで、複数の言語への(ある程度の)マッピングをOODB側が 自動的に行ってくれるとか。 そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、 後はそのオブジェクトに対するシリアライズ/デシリアライズのラッパをかますのと大差ないような気がします。 >>205 RDBで分散キャッシュができれば、現状のOODBの意義はほとんどないと思います。 >>206 ObjectStoreには、Inspectorというツールがあって内容の参照やある程度 の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを 想定されているのなら、そういうものはないでしょう。 >>207 Objectivityは言語非依存のようです。また、Cacheもそうですよね。 OODBってさ、問い合わせ方式は、やっぱり所謂Dictionaryのように、一意のキー(GUIDのような)で 関連付けたりするの? あと関係型(RDB)のSQLや階層型(例えばXMLDB)のXPathに相当する問い合わせ言語がないというのは むしろOODB的にはデメリットだと思うんだけど。 条件付きの検索というのは業務では必須だし、そもそもユニークIDだけで一意にモデリングできるものって 世の中にはあまりない。 検索機能がないのって、例えば履歴書10000枚をキングファイル10冊目にまとめて前に置かれて、 「このキングファイルの中の履歴書にはすべて一意の番号がふってある。 目の前に置いてあるからわざわざ取りに行く必要はない。 さあこの中から○×の条件にあった人材を捜せ」 といわれているのと同じような気がする。 ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。 もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。 >>209 > ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。 > もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。 ODMGは企画倒れになったけど、少なくともVersantにはQuery Languageが有りました。 VersantにはSQLラッパーみたいなのが有って、ROマッピングも出来たように覚えてます。 (5〜6年前の記憶) おまじないカラムを使ってJOINする命令を投げるとと、DBMSではpointer chasingしてくれるという面白いインタフェースです。 もともとOODBには「Query Languageが欲しければ自分でいくらでも好きなよう にプログラムすれば良い」という発想が最初にあったように思います。 でもそれじゃ使いづらいから各社とも付けてますが。 さすがにアーキテクチャ上一番なじみにくそうなObjectStoreでも属性値を指 定して全件検索することぐらい出来るんじゃないかな。 >>208 > ObjectStoreには、Inspectorというツールがあって内容の参照やある程度 > の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを > 想定されているのなら、そういうものはないでしょう。 RDBの「汎用ツール」にしたって、ユーザに公開しているプログラミング用の インタフェースを使って出来ているでしょうから、OODBが特に使いにくいとい うこともないのでは。 あ、RDBだとSQL*Plus見たいなものを自分で作ろうと思えば作れるけど、OODB だと相当面倒なことになるんでしょうか。 「Inspector」を使うためには開発したクラス定義ファイルを読み込ませてや らないといけなくて、Inspectorの中ではかなり高度なことをやっているのかな。 >>207 > そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、 > 後はそのオブジェクトに対するシリアライズ/デシリアライズのラッパをかますのと大差ないような気がします。 こうした、「要するにプログラムの中の変数を保存すればよいんでしょ?」と いう発想が、そもそもOODBや一部オブジェクト指向技術者の間違いだと思いま す。 #207さん失礼。 もともと「データ」はコンピュータを使う前から現実に存在していて、それを コンピュータでどうやって管理するか、という考えからDBMSが出来ていると思 います。 少なくともトランザクション管理や排他制御などを備えたDBMSは、暗黙的にそ うしたことを想定しています。 その点でコンピュータが出来てから発生した画像ファイルとか文書ファイルを 「ファイル→名前をつけて保存」するのとは全く違います。 これは「プログラミング」のみに着目して、プログラムを実行してどうするの かを全く忘れ去ったために起こった履き違えだと思います。 >>205 に出てくる「インピーダンスミスマッチ」も確かに存在するのですが、「インピーダンス ミスマッチ」を理由に履き違えによる本末転倒が広まってしまった気がします。 #OODBがあんまり好きじゃないから、ひどい言い方になってるなぁ、、、 >>212 オブジェクトの永続化は変数の保存とかファイルのセーブなどとは 違う水準の発想だと思うけど。 「オブジェクト」はコンピュータを使う前から現実に存在している もので、オブジェクト指向設計はそれをコンピュータでどうやって 管理するか、という考えだし。:-) >>213 >「オブジェクト」はコンピュータを使う前から現実に存在している いやーそういう原理主義は今は流行ってないよ。 でもデータ中心主義者のいう「エンティティ」と オブジェクト指向主義者のいう「オブジェクト」って 似たり寄ったりの概念だよね >>213 コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。 私にはそうした意味の「オブジェクト」とは非常に抽象化された概念で、「○ ○すること」「○○するもの」と呼べるもの全般を指しているように思えます。 それはDBMSを使った実装とか開発等とは全然別のレイヤの概念で、それに無理 矢理「オブジェクト」と同じ呼称を付けて一緒くたにしているんじゃないでしょ うか。 「オブジェクトの永続化」と「変数の保存」がどのように違う水準で議論 ・考察・活用されているのか教えてください。 #クレクレ君ですいませんが。 OODBって問い合わせ言語は何使うの? SQLじゃないよね? sqlも限定的に使えるのもあったんじゃなかったかな。 cacheかな。何せ使った事がないもんですみません。 >>219 OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。 ODBってJAVAのbeanをそのままDBに格納するのですか? 格納するときはいいけど、selectとかしたらどうなるの? beanの型でデータが返ってくるのですか? (だとしたら、joinとかしたらどうなるのだろう・・・ 新規のbean型を動的に生成するのだろうか?) ODBとオブジェクト指向言語の関係が今ひとつわからない。 要するにオブジェクトを永続させたいのか。 データベースの主張するところはとどのつまりデータの独立だった。 ここのところはどうなるか。それで唐突に思い出したのだが、 IBMシステム38がサンノゼ研究所で1970年代に開発された時、 最大の課題は「停電」だった、と言う話。 このメモリー(プログラム)とデータベースを一体に見ようとした システムでの課題はデータの永続性だったということ。 >このメモリー(プログラム)と → このメモリーと >>225 (偏見に満ちたレスです。) ODBとOOPLを考えるときに、アーキテクチャ全体がどうなっているかとか、 システムがどういう風に稼動・運用・活用されるのかということを考えてはい けません。 目の前のエディタに表示されている作成中プログラムのコードだけに着目しま しょう。オブジェクト指向で楽しくプログラミングしているのにSQLとか変な ものが混ざってきて嫌ですよね。 そこで全てを「オブジェクト」にしてしまえば解決してしまいます。 SQLなんてコンピュータの都合で産まれたもので、それに比べればオブジェク トというこの世に昔から存在しているものを活用すれば、全てがうまくいきます。 「データの独立性が云々」なんて考える必要はありません。 だってそもそもやりたいことはプログラミングなんだし。プログラムのおまけ のデータなんて、適当にディスクへ吐き出しとけばいいんです。 仕事はコンパイルまでで終わりだし、論文や文献の実証実験にもなって一石二鳥ですね。 #一応「皮肉」で書いたつもり。OODBの利点を熱く語る人がいないとネタになっちゃうなぁ。 >>227 素敵なレスです。皮肉でなく。でもここだけは納得できません。 >SQLなんてコンピュータの都合で産まれたもので SQLは論理式(まがい)です。オブジェクトを認識できるものが 論理から超越していることはあり得ません。 あなたの文章はしっかりしていますし、十分に論理的です。 ミドルウエアの適用というのは多分にイマジネーションの世界だと思うんだけど、 やっぱり現時点では具体的に使えそうな業務というか適応分野があまり見当たらないよ。 (別部署のシステムでGemStone+Smalltalkというシステムが1つあるけど、必然性を感じない) それこそかつてのJavlinのようなEJBキャッシュみたいなニッチなところ(業務そのものの データではなく、極めて基盤的なところ)にしか入り込めないという印象。 逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。 >>225 >>227 >>228 >>229 オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。 SQLは集合の性質を記述するもの(内包的な定義)。 >>225 商用システムでオブジェクトという概念を最初に持ち出したのが システム38ですね。良かれ悪しかれ興味深いマシンでした。 いろいろ異論はあろうが、ざっくりと「オブジェクト=データ+手続き」と定義する。 データについては、表現方法を妥当なレベルで共通にできる。 しかし手続きは、言語や処理系によってその表現は異なる。なかなか共通させることはできない。 「オブジェクトの表現形式」を標準化し、それをいろんな処理系からアクセスできるようにする作業が必要になる。 で、それは技術的には可能だ。 だが実際問題としてそこまでやる必要性が薄い。 単にオブジェクトデータベースを使うだけならいつでもできるが、 広い普及はまだまだ無理な状況にある。 BFS1.0やWinFSってRDBだよねぇ。OODBがFSになるのはいつの日か・・・ OODBなファイルシステムっていまいちイメージがつかめんが、 Newtonのsoupとか、BTRONみたいなものかな? >> 234 データはオブジェクトごとに異なりますが、手続きは変わりませんよね。 オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。 また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、 むしろ手続きは永続化対象外でであるべきかと思います。 データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル モデルに変換するひつようがないのであれば価値があると感じます。 RDBMSで現実的なシステムを組むために ストアドとかトリガみたいな機能が必要になったことが、 データと手続きが不可分であることを表していると思うのだが 久々に書きこもう。 >>238 実装(プログラミング)のためにはそうした方が便利という面はあると思う。 だけど実装のために必要になったデータ(ループ変数とかフラグとか関数間受 け渡しための変数とか)と、業務で必要なデータ(顧客名とかIDとか単価とか) は概念上別なものとして認識するのが自然だと思うけど。 OOな人は何故か「とにかくプログラム上は一緒なんだから」という考えのよう な気がして不思議。 OOな人の目的ってやっぱりプログラミング? >>239 よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに 違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって OODBを使いたがるとは限らないよ。 >>240 ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分 なのかということだと思います。 で、私は「永続化すべきデータに違いはない」とまるっきり区別しない事に、 違和感を感じていると書いたつもりです。 (この引用の仕方はU ◆CZtFsGiu0cさんの意図とは違っているかもしれません) あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不 満はいっぱい持っていると思います。しかし私はそこに未だ合理的な理由を見 つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい うような主張にしか見えないのです。 このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん ですが。 >>241 >ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分 なのかということだと思います。 よくわからないな。プログラム上データと手続きが不可分だとしても、永続化 すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。 >あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不 満はいっぱい持っていると思います。 これは、「インピーダンス・ミスマッチ」の一言につきると思います。 設計したモデルをデータストアの都合で崩さなければならない、ということに 不満がありますね。 それから細かいことを言うと、データストアがOODBでない場合はカプセル化を 破るか永続化するデータを持つクラスが永続化の手段を知っている必要がある ので、それはあまり歓迎できないと言うのはあります。 >しかし私はそこに未だ合理的な理由を見 つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい うような主張にしか見えないのです。 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに 壁があるからなんとかできないか、と考えるのは自然ではないですか? >>242 > よくわからないな。プログラム上データと手続きが不可分だとしても、永続化 > すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。 データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が 有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。 > 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに > 壁があるからなんとかできないか、と考えるのは自然ではないですか? プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思 疎通とかいろんな問題があるはずです。 「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて 欲しい」というような主張にしか聞こえてこないんですよ。 >>243 >データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が 有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。 うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは 当たり前だと思うけど、具体的にはどういうことですか? >プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思 疎通とかいろんな問題があるはずです。 「顧客との意思疎通」はともかく、保守・運用やアドホックなデータ検索に 関しては今のOODBはダメダメですよ。それに関する認識はここにもさんざん 書きました。だからこそ、ObjectCacheやCacheに期待するところがあるん ですけどね。 >「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて 欲しい」というような主張にしか聞こえてこないんですよ。 もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の ことしか考えてないってことないですか? プログラムの保守についてはどう 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。 >>244 > うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは > 当たり前だと思うけど、具体的にはどういうことですか? >>239 で書いたようなことです。 「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。 DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。 > もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の > ことしか考えてないってことないですか? プログラムの保守についてはどう > 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。 保守では有りませんが、DBMSの販売に昔かかわっていた者です。 DBはシステムの一部ですが要です。 以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。 ・1つのDBに複数のプログラムがアクセスする場合が非常に多いこと ・システムの稼動に従ってデータ資産が増えていくが、その構造は簡単には変えられないこと ・CPUの速度よりもディスクの速度の方が圧倒的に遅いこと プログラムだってシステムの一部に過ぎません。しかし「『一部』同士だから 検討の優先順位は同等だ」ということにはならないでしょう。 (無論個別の事情によってはいろいろと程度が変わってくると思いますが) 以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと 思います。 >>245 >「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。 DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。 そういうことですか。実装上必要な揮発性のデータを永続化するなんて ありえない、というか「データと手続きが不可分」と言う言葉を曲解してる ように思います。 >DBはシステムの一部ですが要です。 以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。 特に反対することはないんですが、やはり誤解されていると思います。 OOでやってもエンティティはフローズンスポットになるのでそんなに 変更は入りませんし、既存のシステムは当然考慮しますよ。 つかってはみたが・・・ なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・ まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・ OQLの話題ってここ? なんかオレ様の知らないうちにオブジェクトDBシステム用の クエリ言語が標準化されてますた(・へ・) http://www.odmg.org/ 日本語の情報元知ってるひといたらキボンヌ この辺も 「LDP」 http://lambda.uta.edu/lambda-DB/manual/ 「出世魚」 http://www.db.is.kyushu-u.ac.jp/fish/expl/summary.html あとFastDB試してみたらなかなか使いやすかった。 でも誰も使ってない予感 で、複雑で大量の事象と空間をシミュレーションするのに 今現在はどの組み合わせのシステムがベストなの? 多種多様のドキュメントを管理するには何がベスト? 業務処理するには何がベスト? ObjectStoreは,かつてのOO指向のイメージからリアルタイムデータ処理へと変貌した。 たとえば「注文」オブジェクトがあるとする。 注文番号 注文先 商品 単価 個数 消費税額 みたいなオブジェクトだとして。RDBMS だと、注文先番号 や 商品番号で マスタとリレーションするよね。 O/R マッピングだと、マスタとジョインした結果を格納する、ってことができて、 RDBMS におけるメリット(マスタに変更があった場合、オブジェクトにもその 変更が反映できる)を受けられる。 OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに 変更があったらどうするんだろう? マスタデータを表すオブジェクトを更新するだけじゃないの? 注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト ということは、注文オブジェクトの方には、商品マスタオブジェクトのキーを保持 するってこと? 注文番号 注文先キー 商品キー 単価 個数 消費税額 って感じ? これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。 キーっつうか、マスタオブジェクトへのリファレンスだろ?保持するのは。 ごめん。いまいちイメージがわかないや。 具体的にいうとリファレンスって何を保持するの? public class Order { int OrderNo; Comany OrderCompany; Product OrderProduct; BigDecimal UnitPrice; int Quantity; BigDecimal Tax; } ってのを当初考えてたんだけど、これじゃ駄目だよね? それがまさにOODBってことなんだと思ってたんですが。 使ったことねえものわがらん。 当初それで考えてたんだけど、たとえば Product.Name が変更された とするよね、永続化されてる Order クラスには、それがわからないと 思うのですよ。 と思ったんだけど、永続化されるのはあくまで Product クラスの参照であって、 Product クラスの変更は自動的に Order クラスにも伝播するってことかな? XML への永続化とかだと、そうはならないんで、すっかり誤解してました。 クラスという言葉はまぎらわしいからオブジェクトと言ってくれ。 実装によって細部は異なると思うけど基本的には productオブジェクトもorderオブジェクトも、 どちらも永続化されていて、永続化されたDBの中で参照関係が 保持されていると考えるのが普通じゃないかと。 >>259 それはヤバイ。製品仕様が変更になって、商品名が変わったときに、 以前に受けた注文の商品名が変わってしまうと、商売上、会計上 無茶苦茶になる。 業務知識に依存で、参照を持つ方法も取れるし、オブジェクト自体を持つ 事も出来るし、必要な項目だけコピーする事も出来る。 どれを選ぶかは、業務次第。 db4oのアンケート答えたら本が当った、わーい。 実はまともに触ったことないけど、 届いたらじっくり読んで遊んでみることにするよ。 英語苦手だけど。 J○1なんて、変更多かったりいろんなベンダー絡んでくるWEB系噛んでくると当然だが、まったく使えない。 「どうやって直しゃいいーの?やりようねーよ。」って・・・hahaha でもって塩漬け OQLを使える組み込み可能なOODBって何がある? >>268 すまん Javaのやつを探していたのでスルーしてた db4oがOQL使えれば最高なんだがな・・・NQってなんだよorz コンパイル時にチェックできてもポータビリティがないじゃないか db4o、色々実験してみて気に入った。 仕事でも趣味でも使ってる人います? >>272 趣味で弄ろうとしてて苦戦中。 Javaで書いてるんだけどオブジェクトをsaveしたりopenしたりする専用のDAOクラス作った方がいいのかな? >>273 本格的なプログラムの場合はDAO作った方がいいよ。 海外だと弄ってる人多そうだけど、日本は少ないね。 たしかリコーと提携して何かやるとかって話があったけど、 どうなったんだろう。 >>274 中国が積極的みたいだけど日本はね… リコーは開発案件で積極的に導入してるぐらいだと思うけど。 しかしよくエンタープライズで使う気になるよなぁ 日本は盛り上がらんね。 日本語の開発者向けフォーラムもさっぱりだし。 リコーはエンプラじゃなくて組み込みじゃないかな? >>276 そうそう、サンプルが少ないから未だにDAOからオブジェクト追加出来ない俺…orz 組み込みなんだ? 自社製品になら納得。 >>277 サンプルってpdf読んだ?pdf+あっちのフォーラムで解決出来るよ。 Dao作ってる人はQBE?NQ?SODA?どれベースにした? ソートとか考えるとSODAしかないのかな・・・ って1ヶ月前が最終レスか・・・やっぱSODAに行き着いたら離れてくか read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる