TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
MySQL 総合 Part26
SQL質疑応答スレ 19問目
MariaDB
XML統合スレッド
DBを「でーびー」って言う人
【Java】H2 Database Engine【GCJ】
データベース破壊録カイジ
MySQL 総合 Part26
Oracle 質問総合スレ10
CSVファイルのスレ
OODB - オブジェクト指向データベース
- 1 ：03/07/02 〜 最終レス ：2019/11/04
- javaの盛り上がりでOODBに移行していくと思いきや
O-Rマッピングかよ！
語りやがれ！
- 2 ：
- またくそｽﾚ立てやがったか・・・
- 3 ：
- 商用OODB
Objectivity
http://www.objectivity.com/
ObjectStore
http://www.odi.com/
GemStone
http://www.gemstone.com/
Versant
http://www.versant.com/
- 4 ：
- ほっとけほっとけ。
どうせこんなｽﾚすぐにdat落ちするんだからよぉ
- 5 ：
- OODBとRDBの違いを教えて。
OODBは継承ベースデータベースって事？
- 6 ：
- ORDBっつーのもあった気がする
- 7 ：
- XML-DBじゃダメかい？
- 8 ：
- >>6
PostgreSQLのことだっけ?
テーブルの継承とかできるっていう。
使うか? あれ。
- 9 ：
- >>7
面白いけど重すぎ。
- 10 ：
- >>9
重いのか。しかし盛り上がらないなぁ。
まぁOODBってDBを頻繁に扱う人間にとってはどうでもいい存在なんだろうな。
俺はDBドシロウトだからむしろ興味深いんだが。
- 11 ：
- Java用のOODBで実績あるのって何？
- 12 ：
- オブジェクト指向データベースの事が理解できません。
なんか便利そうなのは分るけどリレーショナルとどこが違うのか
やさしく叱りながら教えてください。
- 13 ：
- 「オブジェクト指向データベース」定義が解説書によって
異なっていたりするのには混乱した。
OMGのDB版、ODMGが公開しているのが正しい定義ということでよろしい？
- 14 ：
- OracleはOODB?
- 15 ：
- Object Store PSE: ttp://www.tis.co.jp/product/ostore/OSTORE/PSE/FRAMESET.htm
Objectivity/DB: ttp://www.ogis-ri.co.jp/otc/products/objectivity/index.html
- 16 ：
- うんこーーーーーーーーーーーーー
- 17 ：
- OODBっていうくらいだから、継承ができんのかな？
参照項目をSQLで結んでやんなくてもいいとか？
開発するんだったら楽チンそうですね
- 19 ：
- テストデータ作成とか、データをCSVで作ったり、データのローディングしたり。
こんな作業はどうするの？
- 20 ：
- オブジェクトリレーショナルデータベースと
オブジェクト指向型データベースの違いがわからん。
PostgreSQLはリレーショナルのほうに相当するらしいが。
- 21 ：
- >>20
ObjectStoreについて調べてみれ
- 22 ：
- 遊べるフリーのOODBってないよね？
Zopeが感覚的にかなりOODBに近いと感じたんだけど...
- 24 ：
- オラクルのオブジェクトリレーショナルは、是非使いたいが。
実務での話になると、強引に進めれる相当な強権を持ってるか、
コケてもＯＫなしょぼしょぼの自社内システムでしか作れないな。
まず、あれを使えば、開発側からブーイングが出るやろうし、
なにより、
「速度は、保証できんねんな？」
と迫られれば、
「普通で行きます。」
と答えるしかない。
「速度は、保証できるんか？」
やって。普通のＤＢでも投げるＳＱＬで全然速度は変わるっちゅうねん。畜生。
お前らが、印刷したらＢ４一枚埋まる様な巨大なＳＱＬを投げるから遅いねん。
誰がメンテすんねん。あんなＳＱＬ。
だれか、オラクルのオブジェクトリレーショナルで、ＤＢを構築してしまった
人いる？実務で。
- 25 ：
- >>5
OOのシステムでRDBを使うと、オブジェクトの状態を表形式に変換して保存しなければなりませんが、
OODBはオブジェクトの状態をそのまま永続化できます、属性とか関連とか。
らしい。
http://www.ogis-ri.co.jp/otc/hiroba/technical/objy/step1.html
- 26 ：
- 不勉強ですまんが、OODBって、シリアライズして普通のファイルに保存するのに較べて何か利点あるの？
永続化したいオブジェクトをHashMapに入れて一気に直列化すればトランザクションの
まねごともできるから、あんまOODBの必要性を感じない今日この頃。
- 28 ：
- >>26
ロックとかアクセス権限とか、かなぁ。
- 29 ：
- >>26
ＤＢのなかでもオブジェクトには生きていてほしいんです。
だからトリガやアサーションなんかも。
- 31 ：
- >30
肛門だったらアナルじゃなくてアヌスだろ、馬鹿が。
アナルは「肛門の」という形容詞だ。
他にもオーラル(口の)マニュアル(手の)と色々あるがな。
と宣伝コピペにマジレスしてみる。
しかもこんな時間に。
- 32 ：
- 徹夜中。
OODBって言語に依存せざるをえないと思うんだけど、言語非依存の実装やってる奴ってないのかな。
たとえばC++なんかはリフレクションもないわけで、OODBに格納するのはやりづらそうなんだが...
メモリ内容をそのまま固めたんじゃ、他の言語からアクセスできないしね。
そこらへん、どうにか解決してる実装があったら教えて欲しいです。
- 33 ：
- >>26
例えば，ノードがたっくさんある木構造のオブジェクトで，
どっかのノードを一つだけ update したばあい，
* 直列化 ： 木構造全体を保存する
* OODB ： 修正したノードだけ保存する
と，なるのではないかな．
- 37 ：
- >>33
それって、
class Person { String FirstName; String LastName; }
っていうクラスのオブジェクトでLastNameのみを更新した場合に、
Personのオブジェクト自体は直列化しなおさないってこと？
- 39 ：
- >>37
まあ、イメージとしてはそんなもの。
実際は仮想メモリのページ単位だったりするんだけど。
- 40 ：
- >>39
それはOODBじゃなくてObjectStore。
- 41 ：
- >>40
他のアーキテクチャで代表的な実装ってどんなのがある?
- 42 ：
- >>41
物理的な実装までは知らないけど、Page ServerなのがObjectStore。Versant
なんかがObject Server。なのでVersantは排他制御がオブジェクト単位で可能。
仮想メモリを利用してPage ServerにするのはObjectStoreがパンフで「独自特
許」と誇らしげにしてたから、他のベンダはやってたのかな？
実装の言語依存度合いは
ObjectStore >> Versnat, Objectivity, GEMSTONE >> O2, ITASCA
だった印象が残ってる。（資料比較レベルで）
10年前の知識と記憶だからちょっと不確かかも。Jasmineとかになると全然フォ
ローできない。
http://www.service-architecture.com/index.html
http://galaxy.uci.agh.edu.pl/~vahe/products.htm
このあたりからたどって参考にしてみて。
- 45 ：
- ∧＿∧ ∧＿∧
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
- 46 ：
- (⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
- 47 ：
- OODB復活の先鞭をつけたSybaseの話題が無いのは何故なんだ?
- 48 ：
- SybaseにOODBの製品なんてあったっけ？
- 49 ：
- 何故JASMINEの話が出ないんだ？
- 50 ：
- >>49
あなたを待ってたので
- 51 ：
- いたすかあげ
- 52 ：
- codqlie -silent でお願い．
- 53 ：
- OODBって実績としてはどうなんだ？
- 54 ：
- c++対応のフリーのOODBMSない？
- 55 ：
- jasstop -kill
- 56 ：
- Rerational DBとObject Oriented DBの違い：
Rerational DBは、関係演算に基づいてデータを管理する。
データは複数のテーブルに分けて格納し、テーブル間は外部キーを用いて関係づける。
DBの操作はSQLで行う。そのため、プログラムの開発言語に依存しないという利点はあるが
逆にいえば開発言語とは異なる言語を覚えなけらばならない。
しかもSQLが手順を記述するような言語ではなく、宣言的な言語であるため、覚えるのは結構面倒。
OODBは、『オブジェクトを保存する』という考えを基本にしたDB。
つまりあなたがnewしたインスタンスは何の苦労もなくそのままDBに格納できる。
これがRDBならクラス定義と対応づけたテーブルを用意し、オブジェクトを保存するためのSQLを
いちいち用意しなくてはならない。
またOODBでは開発言語（JavaとかC++とか）でデータベースを操作できるので、SQLを覚えなくてもよい。
それからRDBもOODBも、トランザクション管理とか権限の管理はできる。
これはDBMS(DB Management System)としての機能だから、RDBだろうがOODBだろうが関係ない。
Javaでオブジェクトを保存するだけなら、シリアライズしてファイルに書き込む方法でもいいけど、
こういった機能を使うにはOODBを使うのがよい。
- 57 ：
- すいません、JavaベースでフリーなOODB、Ozoneの評価はどんなものなんでしょう
使っている人います？
http://www.ozone-db.org/frames/home/what.html
- 58 ：
- >>56
> またOODBでは開発言語（JavaとかC++とか）でデータベースを操作できるので、SQLを覚えなくてもよい。
OODBでもQuery Languageは必要では？
上は更新系のことだと思うけど。
- 59 ：
- >>58
必要ないよ。
- 60 ：
- >>59
サンプル教えて。使ったことないせいか、「query(条件文の羅列)」みたいな
のは必要だと思い込んでた。
- 61 ：
- それは、ORDB
サンプルってか、new foo(bar,bu,bi)でインスタンスの生成
foo.updateで更新、foo.siraizeで格納。
こんなイメージで扱えるのがOODB
databaseobject.select(Query)てなイメージが有るの？
- 62 ：
- query(条件文の羅列)
- 63 ：
- >>61
一回格納したインスタンスはどうやって取り出すの？
- 64 ：
- >>63
OODB使え。嘘だと思ってるのか、馬鹿か、どっちかだな（ｗ
- 65 ：
- しらいぜ
- 66 ：
- >> 59
わざわざ2chの書き込みのために使ってみる気はしません。
ちなみに私が「嘘だと思っている」のか「馬鹿」かどっちだと思いますか？
- 67 ：
- すいません。ずれました。
66は64へのレスです。
61であがっているのは更新系だけなので、参照系はどうなのかなと。
SQL99で定義されてない構文だからQLじゃない、という意味じゃないですよねぇ。
大昔VERSANT(1.1の頃)を触ったときにはQLらしきものがあったんですが、今はもう無くなったんですかね。
でもどうやって無くなったんだろう？
＃こんな話をするのは１０年前のNifty以来だ（笑）
- 68 ：
- 1週間止まったな。
61,62,64の人がOODBを熱く語ってくれないかな。
- 69 ：
- では、タダで使えるおすすめのOODBをおしえてちょ？
- 70 ：
- >>69
Ozone
お勧めかどうか知らないが、一応フリーでOODB。
- 71 ：
- Tamino の情報求む！
- 72 ：
- Cache のシングルユーザーライセンス無償版てのではいかんの？
- 73 ：
- Cache'ってホントにOODBなのか？
- 74 ：
- FramerD って使っている人いませんか？
- 75 ：
- ム板にあったリンク集だけれど、
何種類かあるのね。フリーなOODBも。
誰も使ってないのかな？
http://www.linas.org/linux/db-non-sql.html
- 76 ：
- >>67
Zopeしか知らないけれど、
格納とか取り出すって考え方がそもそも無い気がする。
インスタンス作ったら、それがそのまま永続化されてたような。
- 77 ：
- 半年振りにレスがきて懐かしい。
>>76
> 格納とか取り出すって考え方がそもそも無い気がする。
> インスタンス作ったら、それがそのまま永続化されてたような。
ということは、アプリケーションは将来にわたって参照する可能性のあるオブ
ジェクトを、あらかじめ全てハンドリングしているということ？
- 78 ：
- ごめん、俺バカなんで、もうちょっとバカにも分かるように書いてちょうだい(´･ω･`)
- 79 ：
- >>78
すまん、先走りすぎた。
インスタンスを作るとそのまま自動的に永続化されて、後からそのインスタン
スを参照すると自動的に取り出される、と考えて良いんだよね？
立ち上がったアプリケーションがあるインスタンスを参照するためには既にポ
インタを持っているか、ポインタをたどればそのインスタンスへ行き着く、と
想像しているんだけど。
そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
ているインスタンスはどうやって取り出すんだろうか？
そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
装もあるし、MDA絡みでも似たような宣言的構文ができて、｢サーバにリクエス
トを出す→目的のものを受け取る｣ということを昔からやってきてるはず。
ところが上の方のレスだと「OODBならそんなの必要ないじゃん」ということら
しいので、もっと詳しく聞きたかったんだけど。
Query Languageが無いと「suspendとdumpが賢くなって、セーブ機能を簡単に
実装できます｣というような、stand aloneアプリケーション組み込み用のDBに
しかならないような気がする。
- 80 ：
- >>79
ZODBって、Python OrientedなDBっぽいんだけれど、
rootって一番基本になるオブジェクトがあって、
そこから、rootオブジェクトに対して、連想配列みたいな感じで
DBに入ってるインスタンスにアクセス出来るっぽい。
データを格納して検索してっていうよりも、プログラムそのまま入ってるっていうか、
シリアライズ不要で、生のオブジェクトをそのまま格納する場所って感じ？
なんか、自分でも良くわかんなくなってきた。
Cacheなんかは、SQLも使えるらしいし、全然違う物なのかな？
ZODBを使用しているZopeを使用しているだけのユーザなんで、
難しい事分からなくてごめんよ。
- 81 ：
- >>79
OQLってあるみたいだねえ。詳細知らんけど。
http://www.iioss.org/Manual/dbf/dbf9.6.html
- 82 ：
- Matrix
http://www.matrixone.com/
は独自のQLを使っている。
が、速度を無視してくれるなら提供されてるJavaのAPIを使えば
その独自QLを使わなくてもすべてJavaでいける。
オブジェクトの取得はインスタンス化する際に主キー＋αを渡すようなイメージ。
- 83 ：
- >>79
昔、Objectivityを使ってました。
複雑な構造を持つデータと、頻繁なデータの入れ替わりには
ODBMSしかないのでは。
速度がそもそもORDBMSと違います。
イリジウム衛星の軌道制御にも使われていたらしい。
>そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
>ているインスタンスはどうやって取り出すんだろうか？
DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
ちなみに、名前でオブジェクトを関連づけたりできます。
> そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
> 装もあるし、MDA絡みでも似たような宣言的構文ができて、｢サーバにリクエス
> トを出す→目的のものを受け取る｣ということを昔からやってきてるはず。
そもそも、DBのクラスライブラリーに強力なコレクション・クラスがあるので
その検索メソッドを呼び出すなり、そのクラスを使用して強力なコレクション・クラスを作れば
SQLみたいに、文を生成する必要はないです。
ただ、他の言語バージョンに同様のクラス・ライブラリーが移植されていなければ諦めるしかないです。
- 84 ：
- >>83
> 昔、Objectivityを使ってました。
> 複雑な構造を持つデータと、頻繁なデータの入れ替わりには
> ODBMSしかないのでは。
> 速度がそもそもORDBMSと違います。
ここは、キーボードから打ち込む文法の問題なのか、それが実行されるときの
アーキテクチャの問題なのかが一緒になっている気がするので分けて考えたい
です。
> イリジウム衛星の軌道制御にも使われていたらしい。
イリジウム自体が尻つぼみだったけど、当時盛んに宣伝してましたね。総容量
1ペタバイトとうたっていたのはこのプロジェクトでしたっけ?
> DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
> ちなみに、名前でオブジェクトを関連づけたりできます。
そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
てくれるんじゃないでしょうか。
> そもそも、DBのクラスライブラリーに強力なコレクション・クラスがあるので
> その検索メソッドを呼び出すなり、そのクラスを使用して強力なコレクション・クラスを作れば
> SQLみたいに、文を生成する必要はないです。
自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。
「DBMS」という製品パッケージとして成立されるには、当然未知ユーザの未知
の使用方法に応えられるようにしなければならないわけで、その点でRDBの方
が柔軟性が高いように思えます。OODBが自分のソリューションに適合している
かどうかを判断するためには、かなり深いところまで調査する必要があるので
はないでしょうか。実際に記述することになるコードがあらかじめ分かってい
るとか、データへのアクセス統計を把握してそれとOODB内部の動作を照らし合
わせるとか。
どうもOODBが焦点をあてているのは、それまでのDBMSと比べるとシステム全体
の中でのレイヤが1段低いところにあるような気がします。
ちなみにSQLの文法が素晴らしいといっている人は、RDB好きの人の中にもいな
かったと思います。伝道師だったC.J.Dateでさえ文句を言いまくってたみたいだし。
もともとE.F.Coddがリレーショナル代数に基づいたインタフェースを提案した
けど、難しすぎて誰も使おうとしなかったらしい。
今のSQL文法はオペレータがad-hocにリクエストを実行するために、無理に平
文に似せようとして汚くなってるんでしょうね。COBOL開発のバックログに登
録するより端末からSQLをたたいた方が圧倒的に便利だし。
プログラムから呼び出す方法を考えるときに、未知の不定個のデータを扱う良
い方法が無いこともあって、SQLをそのまま埋め込んでループでまわすなんて
いう方法に落ち着いちゃったんでしょう。
埋め込みSQLとは別にCall Level Interfaceもあるけど結局SQLを使いまくるこ
とは変わらなくなっちゃったし。
- 85 ：
- >>84
83じゃないけど
> そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
> てくれるんじゃないでしょうか。
> 自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
> 比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。
そういうのがパッケージとして用意されていれば問題ない気がする。
そのパッケージがＤＢベンダーからそろって提供されれば今のＲＤＢＭＳのように
なるだろうし、Javaで標準ができてCORE APIかJ2EEにでもなろうものなら、どの
ＯＤＢであろうとベンダーによって文法が変わったりとかせずに、それ以前にデー
タへアクセスするソースとかは一切変更しなくていいわけだし。
どっちの方向に行くのか俺には分かんないけどね。
> プログラムから呼び出す方法を考えるときに、未知の不定個のデータを扱う良
> い方法が無いこともあって、SQLをそのまま埋め込んでループでまわすなんて
> いう方法に落ち着いちゃったんでしょう。
ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
してくれるから、そのままオブジェクト指向として使える。
ループで回すって言うなら、RDBに関係なくCOBOLでもそうじゃないのかな。
- 86 ：
- >>85
少し話題が他の方向へ行きましたが。
> そういうのがパッケージとして用意されていれば問題ない気がする。
<snip>
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。
そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
るメリットはどの辺にありそうでしょうか。
> ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。
List, Map, Iteratorそのほかが使えればオブジェクト指向的だと考えてよい
んでしょうか。（この辺の判断基準は良く分かりません）
本題から離れた興味ですが、1回のQuery結果件数が多数になった場合、RDBで
はResultの受け取りをStreamingすることになりますが、ORマッピングツール
(やOODB)でも同様の動作になるんでしょうか。
＃Listのノードを先へたどるときに、｢未取得｣と「最後」の2種類のステータスがあるとか。
それとも全結果が確定してからList等をクライアントで受け取ることになるのでしょうか。
> ループで回すって言うなら、RDBに関係なくCOBOLでもそうじゃないのかな。
COBOLを実際に触ったことが無いから想像ですが、CODASYLにアクセスするとき
はオンライン中はIDによるレコードアクセスでOLTP、オフライン中はバッチ処
理で全件検索というイメージを持ってました。「全件検索」するときにも
COBOLではループしてるんでしょうけど、RDB的なset-at-a-timeなインタフェー
スとはちょっと意味合いが代わってくるのかなと思います。
で、OODBを賛美する人がrecord-at-a-timeなインタフェースだけを取り上げて
いるのが以前(半年前w)の不満点でした。
＃なんか質問ばっかだな。
- 87 ：
- >>86
あんまり詳しくないんですが、
> そうやって標準化／利用便宜のためのレイヤが重なってくるとすると、そのバッ
> クエンドにある格納／トランザクション管理システムをRDBからOODBに移行す
> るメリットはどの辺にありそうでしょうか。
重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
個人的には、RDBに限界を感じてますね。RDBはデータ構造が２次元ですが、階層的に持ちたいって思う事が
多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。
だからオブジェクトとかXMLとかがそのまま格納できりゃあいいんですが、現実問題として考えると・・・
> > ＲＤＢでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> > してくれるから、そのままオブジェクト指向として使える。
> List, Map, Iteratorそのほかが使えればオブジェクト指向的だと考えてよい
> んでしょうか。（この辺の判断基準は良く分かりません）
んー。違いますね。それはまた別問題ですね。
Listに格納されているクラスがオブジェクト指向設計されているかどうかは別の話でしょう。
項目５０個あるからセットするコードを５０行書いてとか自分でBeanをnewしてなんて書かなくても、今のO/R
マッピングツールの中にはそういうのを自動で勝手にやってくれて、Listで返してくれるものもあるよんって意味でかきました。
（マッピングツールが全部そうってわけじゃないけど。）
ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。
> 本題から離れた興味ですが、1回のQuery結果件数が多数になった場合、RDBで
> はResultの受け取りをStreamingすることになりますが、ORマッピングツール
> (やOODB)でも同様の動作になるんでしょうか。
やっぱそうじゃないんでしょうか？ limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
（offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。
問題は、そのくるくる回す部分を「私がプログラミングする必要があるかどうか」じゃないでしょうか？
> ＃Listのノードを先へたどるときに、｢未取得｣と「最後」の2種類のステータスがあるとか。
> それとも全結果が確定してからList等をクライアントで受け取ることになるのでしょうか。
さあ？ ＯＯＤＢってのは誰が（どこで）やるのが一番ベストなんでしょう？
私としては、「私がコーディングする必要があるか否か」が重要であって、ＤＢＭＳが担当しようと、
ＤＢＭＳ以外が担当しようと、速度的に同じであればＤＢＭＳ内に標準化されていようがＤＢＭＳ外で
標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。
次の問題としては、ベンダー（というか製品）によってアクセス方法に違いがあるってことですが（RDBでいうところのSQL)、
これは理想論なんでしょうかね？ SQLが無い時代を考えたら進歩する可能性もあるのかもしれませんね。
＃オブジェクト指向なら、継承で独自拡張路線？
- 88 ：
- >>87
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題（焦点？）であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。
確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。
この手の話だとOODBの特徴について議論しているうちに「要は適材適所」とい
う落ち着かせ所が出て来てしまうんですが、それは初めから当然のこととして
わかっているわけで。
しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
しれませんが。
営業活動の結果としてこんなところで使われているという話よりも、OODBの性
質上こんな使い方が向いているという点が分かりやすく出てこないですかねえ。
最もそれをいうとRDBも別にユーザから「リレーショナルモデルが使いたい」
とか「SQLでコーディングしたい」なんて要望があるわけじゃなくて、クライ
アントサーバがブームになったときにRDBMSぐらいしかそれを実現する手段が
無かったから使われたんだと思いますけど。
> 個人的には、RDBに限界を感じてますね。RDBはデータ構造が２次元ですが、階層的に持ちたいって思う事が
> 多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
> 変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。
そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
OODBでは「プログラム中の構造がそのまま格納できる」というのを売りにして
いますが、じゃあRDBでは「プログラム中で頻繁に使う2次元配列を簡単に格納
できる」のが売りかというと全然そんなこと無いし。
変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
ピンと来ません。
そりゃあコンパイルしてテスト通して納品しておしまいなら良いんですが、そ
れまでシステムが稼動して蓄積してきたデータ資産や他アプリケーションがあ
るわけで。
異なるオブジェクトモデル間をコンバートやラッピングする手法／ツールが出
てきてるんでしょうか?
しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。
- 89 ：
- >>87
長くなったので分割。
> ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。
ごりごりプログラムしているわけではないので詳しくは分かりませんが、なん
となく理解できました。
> やっぱそうじゃないんでしょうか？ limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
> （offsetとかもありましたっけ？）、そうじゃなけりゃくるくる回してるでしょう。
limit等は最終的に返す個数の指定ですが、RDBなどでは例えば検索結果が100
万件あったら確定した結果が順次クライアントへ送られる、という意味で
「Streaming」と書きました。クライアントが1件目の結果を処理しているとき
はサーバは50万件目を探しているかもしれない。
> 私としては、「私がコーディングする必要があるか否か」が重要であって、ＤＢＭＳが担当しようと、
> ＤＢＭＳ以外が担当しようと、速度的に同じであればＤＢＭＳ内に標準化されていようがＤＢＭＳ外で
> 標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。
私としては、システムというのは動かして使われるためのものなので、コーディ
ングの便宜よりもどういうアーキテクチャで動くのかとか、稼動させたときの
運用制限はどうなるのかという点の方を重視したいです。
実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
して動作するんだし。
＃暑すぎて仕事がはかどらないくせに長文w。 2chに文字数制限があるのをはじめて知った。
- 90 ：
- >>88
> 確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
> なのかのイメージがつかめません。
> 世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
> 便利」というのが分かりづらいです。
んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> しかもOODBベンダ等は｢ポストRDB｣として売り出して「将来は入れ替わる」と
> いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
> しれませんが。
速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。
今はそれに変わって既存のＲＤＢがオブジェクトもいけますよっていうＯＲＤＢがでてきてますね。Oracleしかり、MSSQLしかり。
まあ、これからのもんでしょうけど。
- 91 ：
- >>88
ああ、長くなったので分割したら、後半がきえてしまった。orz
> そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
> 葉のアヤであって、別に2次元でモデル化しようというわけでもないし。
RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
状態になったり、今まで必須だった項目がまったく不要になったり、、
結構頻繁にあるんですよねえ。
＃うちの会社だけ？
> 変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
> ピンと来ません。
んー、オブジェクト指向だからってことはないのかもしれませんねえ。
> 異なるオブジェクトモデル間をコンバートやラッピングする手法／ツールが出
> てきてるんでしょうか?
O/Rマッピングツールでしたら、私のお薦めはこれ。
http://www.ibatis.com/common/sqlmaps.html
> しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
> たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。
仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は２つあります。
・一から作り直す。
・今のを修正して、無理にでも動かす。（もち問題先送り）
で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、
- 92 ：
- >>89
> 実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
> ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
> して動作するんだし。
別にJ2EEのようにインターフェイスだけ共通で定義されていて、実装は各ベンダーが
行ってもいいわけです。
私は
「この条件に従ってデータを取ってこい。それが仮に５０万件あろうと、このソー
トキーに基づき４１〜６０件目の２０件だけデータを返せ。」
という命令がしたいだけ。
- 93 ：
- >>90
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計（モデリング）して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま（オブジェクトのまんま）格納
> や抽出なんかができれば便利なわけです。だからＯＯＤＢの登場ですよね。
あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。
少なくともそうしたものを暗黙的に想定します。
> 別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
これも不思議です。プログラムの構造そのままに格納したいのであれば、オブ
ジェクト指向云々とは全く関係なくその要望はあるように思います。例えば
ObjectStoreがプログラム実行時の仮想メモリをそのまま保存できるからすご
いんだ、と宣伝していましたが、仮想メモリはオブジェクト指向によってもた
らされたものではないですし。
> 速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
> 市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。
「OODBは速い」というのは昔々のoo1やOO7ベンチマークでjoinとpointer chasingを
比較したところから始まっていると思いますが、そのときの比較はRDBもOODB
も研究用プロトタイプで行っていたように思います。実際の性能なんてモデル
なんかよりも実装テクニックの方がはるかに影響が大きいと思うんですけど。
結果やその伝聞を真に受けて「RDBをOODBに入れ替えれば速度が1000倍になる」
と早合点して、無茶なシステムの企画を立てた人がもしかしたらいたのかも。
＃そういえばObjectStoreに不利な結果が出たから弁護士を使って論文から削
＃除させたこともあったような。
- 94 ：
- >>91
> RDBは現実のモデルを正規化という手法によって２次元のテーブルを設計していくわけですよね。
2次元の表ではなくて、正式にはリレーションだし、現実的には単なるレコー
ド設計でしょう。レコードを沢山集めて2次元に表示できるということなら、
オブジェクトを集めたって同じことが言えると思います。
複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
queryが付いたりする。
> システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
> 状態になったり、今まで必須だった項目がまったく不要になったり、、
> 結構頻繁にあるんですよねえ。
ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
うなんでしょうか。
> O/Rマッピングツールでしたら、私のお薦めはこれ。
> http://www.ibatis.com/common/sqlmaps.html
O/Rマッピングというよりも、既存のオブジェクト指向モデルがあってそれが
すでに稼動している場合、前提条件が覆ってモデルの変更が発生した場合に、
旧モデルから新モデルへの移行は現在保存されているオブジェクトを含めて自
明な方法になるんだろうか、という疑問です。
MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印
象を持っていますが。
> 仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は２つあります。
> ・一から作り直す。
> ・今のを修正して、無理にでも動かす。（もち問題先送り）
> で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
> まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、
この場合の一番の判断要因はもちろんコストでしょう。
- 95 ：
- >>93
> あぁ、この辺の感覚が私とは違いますね。｢プログラムの中にあるデータを格
> 納したい」とは考えないです。
研究者の方ですか？
> だってデータはコンピュータシステムが出来る
> 前から存在していて、システムの外で発生して人間が入力するもので、いざと
> なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
> には可能です。
えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
水道は、電気は、車は、
ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
やっぱり私とは考え方というか感覚が違いますね。（だから楽しい！）
> > 別にＣやＣＯＢＯＬのようなオブジェクト指向言語でないもので開発を行うのであれば、ＯＯＤＢなんてまったく無意味でしょう。
> これも不思議です。
不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
- 96 ：
- >>94
> レコードを沢山集めて2次元に表示できるということなら、
> オブジェクトを集めたって同じことが言えると思います。
そうかもしれません。
> 複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
> queryが付いたりする。
だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
> ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる／なりそ
> うなんでしょうか。
んー。正確には、適切に設計されていればコードの変更箇所が必要最小限となり、影響される範囲も限定されるわけです。
DBどうのこうのじゃなくて、システム設計の話になりますね。
で、言語で言えば、BASICに比べればCが、Cに比べればJavaが、「適切に設計」されてさえいれば安全性が増しますね。
JavaだからOODBとなったわけで、BASICやCOBOLならシーケンシャルファイルでしょうか。
話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。（ｗ
> MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印
すいません。MDAって何ですか？
> この場合の一番の判断要因はもちろんコストでしょう。
ビジネスの世界ではコストより時間が優先されがちです。
時間＝コストと考えれば、コストですね。
- 97 ：
- >話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。（ｗ
それは幻想のような。
ただのプログラムだって最初の分析が甘ければデータ構造の
見直しが発生しちゃうわけだし。
逆にDOAなど分析手法が確立しているRDBの方が危険性が
少ないようにも思うんだが。
- 98 ：
- >>97
よく分かんない。
まあだいたいトレードオフするものだから、どっからみても完璧なんてあり得ないんだけど、
もし仮にそういう完璧な設計&プログラミングができたとしても、それはその時点でのモデルだよね。
- 99 ：
- >>98
どうせ完璧なんて無いんだから、どうしたら「マシ」なのかを探るべきだと思います。
＃週末で酔っぱらってるので本レスはまた来週。
- 100 ：
- >>99
１）業務を変えない。 無理だな。
２）業務を変えるたびにシステム再構築し直す。 無理だな。
３）業務に変更があった場合、修正箇所を最小限にする。
なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
- 101 ：
- >>100
> ３）業務に変更があった場合、修正箇所を最小限にする。
> なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。
それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
で展開してた議論だと思います。
- 102 ：
- >>101
> 過去のプログラムの実行結
> 果を格納しているＤＢの場合はどんな考察になるんでしょう？というのがここ
> で展開してた議論だと思います。
そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
> それはプログラミングの場合は確立されてるけど、
だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
#現実的にはRDBしか選択肢がないに等しいんだけどね。
- 103 ：
- >>102
> そうだっけ？ 別にRDBからOODBに移行する話じゃなかったと思うんですが。
そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの？」と
いうのが話（やそもそものスレ）の発端でしょ？
> だから言語に合わせて（オブジェクト指向分析・設計で）オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのは>>100の（３）に相反しているというのが私の主張です。
それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。
上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
システム開発ってプログラミング関連だけじゃなくて方式設計とか、ネットワー
ク設計とか、ソフトウェア構成とか、いろんな要素が絡んでると思うんだけど。
その時に「DBMS」と呼ばれる構成要素に対して求められる機能を考えたときに、
RDBやOODBはどんな特徴として位置づけられるんだろう、と考えるのが重要だ
と思います。
- 104 ：
- >>95
> 研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。
OODB出始めは本当にアカデミック方面しか資料が無かったし。
でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、
> えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。
カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。
企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。
データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。
> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？
少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。
> 経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、
水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
＃極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。
> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。
実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?
システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
＃制御系の話はよく分からないんでパス。
> 不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
> ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。
パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。
相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
- 105 ：
- >>96
> だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません？
プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
> オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。
オブジェクト指向以外の言語において、プログラミングの便宜のためにレコー
ドの概念が導入されたとは思えません。それは言語の問題の外からの要求に応
えたものだと思います。そしてその関係はオブジェクト指向言語でも変わるべ
きではないと思います。（というか変わる理由が分からない）
> すいません。MDAって何ですか？
Model Driven Architecture(だったかな?)。標準的なオブジェクト指向の道具
立てがそろってきたから、ここらでもう1回CASEの夢を見ようという動きだと、
私は理解をしています。
> ビジネスの世界ではコストより時間が優先されがちです。
> 時間＝コストと考えれば、コストですね。
すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
沢山出て来そう)ということでしょうか。
＃新規の話じゃないですよね。
まあ実際は資産を除却するよりも、追加で出来るならそっちの方が良いという
判断かもしれませんが。
- 106 ：
- >>103
>それに対して「別にＤＢは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。
DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか？
それとも相互に影響を与えながら進化していっているのでしょうか？
>>研究者とくるとは、、、
それとも学生か学者かと。
>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理
別に揚げ足じゃないですが、判を押した請求書をつくらないところもありますよ。入金チェックは自動でしているところもあるでしょう。
人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。
>便利な手段があるからといって、目的と混同すべきではないです。
便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
手段や目的とはその上で語られる別次元のものです。
>パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
>チして、サーバのディスクからページを転送してくるらしいです。
面白そうですね。OSいらんやんって思いました。
OSいるんですかね？ httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。
- 107 ：
- >相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。
>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。
外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。
>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
これはOODBの場合って話ですか？ なぜでしょう？
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。
>Model Driven Architecture(だったかな?)。
JavaWorldの５月号に特集を見つけました。今度読んでみます。
>> ビジネスの世界ではコストより時間が優先されがちです。
>> 時間＝コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。
いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし５ヶ月かかる。
・今のをむりやりにでも動くように修正すれば１ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、４ヶ月の時間差（＝コスト）がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に４ヶ月分だけの価値（＝利益）があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。
- 108 ：
- なんか盛り上がってますね。現役のObjectStore使いです。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
>>88
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
＃ただし私が関わっているシステムはそのどちらでもありません
>>90
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
悲惨です。クライアントのキャッシュが肥大してメモリ不足になってしまう
なんてこともあります。
OODBが通常の業務システムに使われないのは、まず技術者が不足している
こと、ベンダのサポートが不安なこと(今はわかりませんが、昔はひどい
もんでした)、それとなにより業務システムにありがちなアドホックなデータ
操作(参照系、更新系含む)が難しいことでしょうか。なにかあるたびに
プログラムを一本作らなければならないのでは、運用が困難です。
ただ、個人的にはOODB(っていうかObjectStore)のキャッシュが使えたらな
、と思うことはよくあります。どんなデータかというと、
・参照は頻繁にされる。また、参照のコストが高い
・更新の頻度は少ないが、更新は即時に反映される必要がある
ようなものです。例えばリソースに対するアクセス制御データとかですね。
- 109 ：
- 非常に面白いスレですね。OODB未経験ですが割り込ませてください。
（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）
今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？
実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
（最終的にはCORBA/CCMまで絡ませたい）
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること（ユーザインターフェイスを含む）」なのです。
（以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。）
ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
（MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう）。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ（例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール）が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか？
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
（ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします）
- 110 ：
- 続き。
あと個人的な意見ですが、OODB（やXMLDB）がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
まずは上級エンジニアが触ってみて遊んでみて「いいな、コレ」って思ってもらわなければ、いつまでたっても一部のコアな開発者のマニアックな玩具に留まってしまう気がします。
それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応（←これ重要！2バイト対応されていない製品はユーザに嫌われる）
といったようなものがサクっと出てくるようでないと・・・。
（フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・？）
100〜のスレッドの続きを読む
データベース技術を勉強したいのですが…
【M言語】キャシエ・CACHE【MUMPS】
DB設計を語るスレ 10
【PureJava】 Derby 1 【OpenSource】
SQL質疑応答スレ 18問目
【レア技術者】 ORACLE DEVELOPER R6i 【狂え！】
MySQL 5.0
はじまりです。
【】 MySQLを買収したSunを買収したOracleを 【】
【9i】オラクルマスターGOLDのスレ【10g】
--------------------
君が望む永遠 第100章
【ﾚｰｽﾞﾝｺﾘｺﾘ】牧野結美 109粒【世界中が震撼】
夢
【東海ラジオ】 DON-TSUKI 【1332】
代官山〜学芸大学 渋谷 外苑前 広尾 赤坂いまひま
正直、自民党がここまでバカだとは思ってなかったやつの数→ [298176652]
西村理香
なぜ正月の寄席はあんなにもつまらないのか？！！
一騎当千のフィギュアを語るスレ Part17
【BOINC】48Gファンもがん･難病解析★47【@akb】
【μ】名古屋鉄道285号車【名鉄】〜転載禁止〜
【バーチャルYoutuber】にじさんじ有ンチスレ10787【リゼ天皇からのバトンを落としたちーさん】
ラーメン二郎 新・新代田店 11店目
■■ＡＫＢ師匠ゴールデン 視聴率７．１■■
ブルージーなピアニスト
【古豪復活へ】立教大学アイスホッケー【期待大】
よく「氷河期は結婚出来ない」って言うが年収400あれば結婚出来ると思うんだが
電話占いで人生狂わされた人
増税前オフ会
【自治】とびだせどうぶつの森 ｱｲﾃﾑ交換【議論】2
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
