OODB - オブジェクト指向データベース (311ﾚｽ)
上下前次1-新
85(2): 04/07/16 12:18 ID:??? AAS
>>84
83じゃないけど
> そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
> てくれるんじゃないでしょうか。
> 自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
> 比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。
そういうのがパッケージとして用意されていれば問題ない気がする。
そのパッケージがＤＢベンダーからそろって提供されれば今のＲＤＢＭＳのように
なるだろうし、Javaで標準ができてCORE APIかJ2EEにでもなろうものなら、どの
ＯＤＢであろうとベンダーによって文法が変わったりとかせずに、それ以前にデー
省8
86(1): [age] 04/07/20 15:03 ID:??? AAS
>>85
少し話題が他の方向へ行きましたが。
> そういうのがパッケージとして用意されていれば問題ない気がする。
<snip>
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。
そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
るメリットはどの辺にありそうでしょうか。
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
省17
87(2): 85 04/07/20 22:40 ID:??? AAS
>>86
あんまり詳しくないんですが、
> そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
> クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
> るメリットはどの辺にありそうでしょうか。
重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
省29
88(3): [age] 04/07/21 13:54 ID:??? AAS
>>87
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。
省29
89(1): [age] 04/07/21 13:56 ID:??? AAS
>>87
長くなったので分割。
> ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。
ごりごりプログラムしているわけではないので詳しくは分かりませんが、なん
となく理解できました。
> やっぱそうじゃないんでしょうか？ limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
> （offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。
limit等は最終的に返す個数の指定ですが、RDBなどでは例えば検索結果が100
万件あったら確定した結果が順次クライアントへ送られる、という意味で
「Streaming」と書きました。クライアントが1件目の結果を処理しているとき
省11
90(3): 04/07/21 22:19 ID:??? AAS
>>88
> 確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
> なのかのイメージがつかめません。
> 世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
> 便利」というのが分かりづらいです。
んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
省6
91(1): 04/07/21 22:32 ID:??? AAS
>>88
ああ、長くなったので分割したら、後半がきえてしまった。orz
> そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
> 葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
状態になったり、今まで必須だった項目がまったく不要になったり、、
結構頻繁にあるんですよねえ。
＃うちの会社だけ？
省14
92: 04/07/21 22:38 ID:??? AAS
>>89
> 実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
> ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
> して動作するんだし。
別にJ2EEのようにインターフェイスだけ共通で定義されていて、実装は各ベンダーが
行ってもいいわけです。
私は
「この条件に従ってデータを取ってこい。それが仮に５０万件あろうと、このソー
トキーに基づき４１〜６０件目の２０件だけデータを返せ。」
という命令がしたいだけ。
93(1): [age] 04/07/23 12:46 ID:??? AAS
>>90
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
> や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。
少なくともそうしたものを暗黙的に想定します。
省16
94(1): [age] 04/07/23 12:55 ID:??? AAS
>>91
> RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
2次元の表ではなくて、正式にはリレーションだし、現実的には単なるレコー
ド設計でしょう。レコードを沢山集めて2次元に表示できるということなら、
オブジェクトを集めたって同じことが言えると思います。
複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
queryが付いたりする。
> システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
> 状態になったり、今まで必須だった項目がまったく不要になったり、、
> 結構頻繁にあるんですよねえ。
省16
95(1): 04/07/23 21:28 ID:??? AAS
>>93
> あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
> 納したい」とは考えないです。
研究者の方ですか？
> だってデータはコンピュータシステムが出来る
> 前から存在していて、システムの外で発生して人間が入力するもので、いざと
> なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
> には可能です。
えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
省10
96(1): 04/07/23 21:43 ID:??? AAS
>>94
> レコードを沢山集めて2次元に表示できるということなら、
> オブジェクトを集めたって同じことが言えると思います。
そうかもしれません。
> 複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
> queryが付いたりする。
だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
> ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
> うなんでしょうか。
省10
97(1): 04/07/23 23:19 ID:??? AAS
>話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。（ｗ
それは幻想のような。
ただのプログラムだって最初の分析が甘ければデータ構造の
見直しが発生しちゃうわけだし。
逆にDOAなど分析手法が確立しているRDBの方が危険性が
少ないようにも思うんだが。
98(1): 04/07/24 16:35 ID:??? AAS
>>97
よく分かんない。
まあだいたいトレードオフするものだから、どっからみても完璧なんてあり得ないんだけど、
もし仮にそういう完璧な設計&プログラミングができたとしても、それはその時点でのモデルだよね。
99(1): [age] 04/07/25 01:31 ID:??? AAS
>>98
どうせ完璧なんて無いんだから、どうしたら「マシ」なのかを探るべきだと思います。
＃週末で酔っぱらってるので本レスはまた来週。
100(3): 04/07/25 10:28 ID:??? AAS
>>99
１）業務を変えない。 無理だな。
２）業務を変えるたびにシステム再構築し直す。 無理だな。
３）業務に変更があった場合、修正箇所を最小限にする。
なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
101(1): [age] 04/07/25 10:40 ID:??? AAS
>>100
> ３）業務に変更があった場合、修正箇所を最小限にする。
> なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
で展開してた議論だと思います。
102(1): 04/07/25 21:40 ID:??? AAS
>>101
> 過去のプログラムの実行結
> 果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
> で展開してた議論だと思います。
そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
> それはプログラミングの場合は確立されてるけど、
だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
#現実的にはRDBしか選択肢がないに等しいんだけどね。
103(1): [age] 04/07/25 23:45 ID:??? AAS
>>102
> そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの？」と
いうのが話（やそもそものスレ）の発端でしょ？
> だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。
上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
省5
104(1): [age] 04/07/26 14:10 ID:??? AAS
>>95
> 研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。
OODB出始めは本当にアカデミック方面しか資料が無かったし。
でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、
> えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
省29
上下前次1-新書関写板覧索設栞歴
あと 207 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 3.613s*