X

OODB - オブジェクト指向データベース

0200NAME IS NULL
垢版 |
04/10/12 15:42:35ID:???
>>199
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。

POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。
0201NAME IS NULL
垢版 |
04/10/13 17:13:49ID:???
>>200
> CORBA自体が下火だからでしょうか。

結局水平分散はコンセプトとしては美しいけど、方式設計や運用設計が難しかっ
たんですかね。

だからといってEJBや.NETの世界に行っても、ヘテロジニアスなストレージレ
イヤの水平分散・統合が簡単になることもなさそうと思ってるんですけど、実
際どんな感じなんでしょう?＞使っている方。

Entity BeanやEJBの分散トランザクション管理機能(DBMSにdispatchするだけ
じゃなくて)がここまで進化した、というような話はあるでしょうか?
0202NAME IS NULL
垢版 |
04/11/25 18:55:24ID:pQRP4O3e
ttp://www.atmarkit.co.jp/fdb/single/01_rfid_database/rfid_database01.html
RFID、ECサイトに求められるデータベース性能とは？

>バックエンドのRDBMSはそのままに、
>フロントエンドのデータ・キャッシングに「ObjectStore 注」のファミリ製品であるObjectCacheを導入することで、
>Linuxマシン上で稼働する4つのObjectCacheインスタンスにリプレイスでき、コストを大幅に削減できました

>同期処理時間は12時間から1分以内に改善され、応答速度も向上しています。

理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？
0203NAME IS NULL
垢版 |
04/11/26 11:10:13ID:???
>>202
> 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか？

使っているのはOODBじゃなくて、キャッシュでは?

機能を想像してみると、RDBのデータをどの単位か分からないけれどフロント
エンドマシンにキャッシュして、OOPLから透過にアクセスできる、というもの
じゃないでしょうか。
RDBMSのデータキャッシュページと連動させていたら結構すごい機能だと思う
けど、やってるのかな。

ディスクじゃなくてメモリにすれば、そりゃ速くなるでしょうね。

「同期処理」とか注文処理のトランザクションの内容やタイミングが分からな
いから、どの程度キャッシュの賢さが効いているのか分からないけど。もとも
との設計がタコだったのかもしれないし。

数年前のシステムを公開しているのだと仮定すると、当時と比べればIAサーバ
の性能も上がってコストも安くなってるだろうし、Linuxも最近ようやく使い
物になってきたし。この辺はObjectCacheとは全然関係ないですね。

ところで、ObjectStoreっていつの間にか買収されてたんですね。3年ぐらい前
はXMLブームに乗って「今後はXMLに特化した製品・会社になる」と宣言してい
たような気がしたんですが、最近はEC・リアルタイムに特化なんでしょうか。
0204NAME IS NULL
垢版 |
04/12/02 00:53:48ID:???
Cach？を使ってみたいのに、手早くMySQLに逃げてしまう漏れ。
自宅ではMacOSXなので動かん。どうしょ。
0205NAME IS NULL
垢版 |
04/12/15 00:08:43ID:???
>>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はニッチな市場しかないじゃないかな。

0206NAME IS NULL
垢版 |
04/12/15 23:12:48ID:eJ+2vIrC
質問なんですが、OODBに格納されているデータを覗くには、とにもかくにもプログラムインターフェイスを介さないと見れないのでしょうか？
OracleのSQL*Plusとか、それこそAccessみたいな感じのビューワってあるんでしょうか？
（簡単にデータの格納状態がエビデンスとして見れるツールがないと開発には使えない）

まぁ仮にそういうツールがあったとしても、おそらくそういったビューワでオブジェクトを参照できるようにするためには
そのオブジェクトがOODB製品が提供する独自のツール表示用interfaceを実装する必要があるとか、
そういう仕組みがあるのでしょうけど。

0207NAME IS NULL
垢版 |
04/12/15 23:14:53ID:eJ+2vIrC
あと>>32にも書いてあるが、クロス言語を実現できる製品はあるのでしょうか？
例えばOODBの提供するinterdaceを実装することで、複数の言語への（ある程度の）マッピングをOODB側が
自動的に行ってくれるとか。
そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。
0208U ◆CZtFsGiu0c
垢版 |
04/12/16 12:14:07ID:???
>>205
RDBで分散キャッシュができれば、現状のOODBの意義はほとんどないと思います。

>>206
ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
想定されているのなら、そういうものはないでしょう。

>>207
Objectivityは言語非依存のようです。また、Cacheもそうですよね。
0209NAME IS NULL
垢版 |
04/12/17 01:07:40ID:???
OODBってさ、問い合わせ方式は、やっぱり所謂Dictionaryのように、一意のキー（GUIDのような）で
関連付けたりするの？
あと関係型（RDB）のSQLや階層型（例えばXMLDB）のXPathに相当する問い合わせ言語がないというのは
むしろOODB的にはデメリットだと思うんだけど。
条件付きの検索というのは業務では必須だし、そもそもユニークIDだけで一意にモデリングできるものって
世の中にはあまりない。

検索機能がないのって、例えば履歴書10000枚をキングファイル10冊目にまとめて前に置かれて、
「このキングファイルの中の履歴書にはすべて一意の番号がふってある。
　目の前に置いてあるからわざわざ取りに行く必要はない。
　さあこの中から○×の条件にあった人材を捜せ」
といわれているのと同じような気がする。

ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。
0210NAME IS NULL
垢版 |
04/12/20 19:34:13ID:???
>>209
> ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
> もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。

ODMGは企画倒れになったけど、少なくともVersantにはQuery Languageが有りました。
VersantにはSQLラッパーみたいなのが有って、ROマッピングも出来たように覚えてます。
（5〜6年前の記憶）
おまじないカラムを使ってJOINする命令を投げるとと、DBMSではpointer
chasingしてくれるという面白いインタフェースです。

もともとOODBには「Query Languageが欲しければ自分でいくらでも好きなよう
にプログラムすれば良い」という発想が最初にあったように思います。

でもそれじゃ使いづらいから各社とも付けてますが。
さすがにアーキテクチャ上一番なじみにくそうなObjectStoreでも属性値を指
定して全件検索することぐらい出来るんじゃないかな。
0211NAME IS NULL
垢版 |
04/12/20 19:42:09ID:???
>>208
> ObjectStoreには、Inspectorというツールがあって内容の参照やある程度
> の操作ができます。他のOODBにもありそうですけどね。もし汎用のツールを
> 想定されているのなら、そういうものはないでしょう。

RDBの「汎用ツール」にしたって、ユーザに公開しているプログラミング用の
インタフェースを使って出来ているでしょうから、OODBが特に使いにくいとい
うこともないのでは。

あ、RDBだとSQL*Plus見たいなものを自分で作ろうと思えば作れるけど、OODB
だと相当面倒なことになるんでしょうか。

「Inspector」を使うためには開発したクラス定義ファイルを読み込ませてや
らないといけなくて、Inspectorの中ではかなり高度なことをやっているのかな。
0212NAME IS NULL
垢版 |
04/12/20 19:57:25ID:???
>>207
> そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
> 後はそのオブジェクトに対するシリアライズ／デシリアライズのラッパをかますのと大差ないような気がします。

こうした、「要するにプログラムの中の変数を保存すればよいんでしょ？」と
いう発想が、そもそもOODBや一部オブジェクト指向技術者の間違いだと思いま
す。
＃207さん失礼。

もともと「データ」はコンピュータを使う前から現実に存在していて、それを
コンピュータでどうやって管理するか、という考えからDBMSが出来ていると思
います。

少なくともトランザクション管理や排他制御などを備えたDBMSは、暗黙的にそ
うしたことを想定しています。

その点でコンピュータが出来てから発生した画像ファイルとか文書ファイルを
「ファイル→名前をつけて保存」するのとは全く違います。

これは「プログラミング」のみに着目して、プログラムを実行してどうするの
かを全く忘れ去ったために起こった履き違えだと思います。

>>205に出てくる「インピーダンスミスマッチ」も確かに存在するのですが、「インピーダンス
ミスマッチ」を理由に履き違えによる本末転倒が広まってしまった気がします。

＃OODBがあんまり好きじゃないから、ひどい言い方になってるなぁ、、、
0213NAME IS NULL
垢版 |
04/12/28 11:16:29ID:???
>>212
オブジェクトの永続化は変数の保存とかファイルのセーブなどとは
違う水準の発想だと思うけど。

「オブジェクト」はコンピュータを使う前から現実に存在している
もので、オブジェクト指向設計はそれをコンピュータでどうやって
管理するか、という考えだし。:-)
0214NAME IS NULL
垢版 |
04/12/28 18:55:28ID:???
>>213
＞「オブジェクト」はコンピュータを使う前から現実に存在している
いやーそういう原理主義は今は流行ってないよ。
0215NAME IS NULL
垢版 |
05/01/07 10:00:37ID:???
でもデータ中心主義者のいう「エンティティ」と
オブジェクト指向主義者のいう「オブジェクト」って
似たり寄ったりの概念だよね
0216NAME IS NULL
垢版 |
05/01/07 20:25:08ID:???
>>213
コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。

私にはそうした意味の「オブジェクト」とは非常に抽象化された概念で、「○
○すること」「○○するもの」と呼べるもの全般を指しているように思えます。

それはDBMSを使った実装とか開発等とは全然別のレイヤの概念で、それに無理
矢理「オブジェクト」と同じ呼称を付けて一緒くたにしているんじゃないでしょ
うか。

「オブジェクトの永続化」と「変数の保存」がどのように違う水準で議論
･考察・活用されているのか教えてください。

＃クレクレ君ですいませんが。
0219NAME IS NULL
垢版 |
05/01/19 04:16:16ID:???
OODBって問い合わせ言語は何使うの？
SQLじゃないよね？
0220NAME IS NULL
垢版 |
05/01/19 10:25:43ID:???
sqlも限定的に使えるのもあったんじゃなかったかな。
cacheかな。何せ使った事がないもんですみません。
0221U ◆CZtFsGiu0c
垢版 |
05/01/19 16:12:01ID:???
>>219
OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。
0222NAME IS NULL
垢版 |
05/01/19 18:26:09ID:???
ODBってJAVAのbeanをそのままDBに格納するのですか？
格納するときはいいけど、selectとかしたらどうなるの？
beanの型でデータが返ってくるのですか？
（だとしたら、joinとかしたらどうなるのだろう･･･
新規のbean型を動的に生成するのだろうか？）
0223NAME IS NULL
垢版 |
05/02/19 21:10:21ID:nDi7jRio
Cach?
0225NAME IS NULL
垢版 |
05/02/19 22:37:33ID:zu8T/EQb
ODBとオブジェクト指向言語の関係が今ひとつわからない。
要するにオブジェクトを永続させたいのか。
データベースの主張するところはとどのつまりデータの独立だった。
ここのところはどうなるか。それで唐突に思い出したのだが、
IBMシステム38がサンノゼ研究所で1970年代に開発された時、
最大の課題は「停電」だった、と言う話。
このメモリー(プログラム)とデータベースを一体に見ようとした
システムでの課題はデータの永続性だったということ。
0226225訂正
垢版 |
05/02/19 22:42:32ID:zu8T/EQb
>このメモリー(プログラム)と → このメモリーと
0227NAME IS NULL
垢版 |
05/02/21 15:29:18ID:???
>>225
(偏見に満ちたレスです。)

ODBとOOPLを考えるときに、アーキテクチャ全体がどうなっているかとか、
システムがどういう風に稼動・運用・活用されるのかということを考えてはい
けません。

目の前のエディタに表示されている作成中プログラムのコードだけに着目しま
しょう。オブジェクト指向で楽しくプログラミングしているのにSQLとか変な
ものが混ざってきて嫌ですよね。

そこで全てを｢オブジェクト｣にしてしまえば解決してしまいます。

SQLなんてコンピュータの都合で産まれたもので、それに比べればオブジェク
トというこの世に昔から存在しているものを活用すれば、全てがうまくいきます。

「データの独立性が云々」なんて考える必要はありません。
だってそもそもやりたいことはプログラミングなんだし。プログラムのおまけ
のデータなんて、適当にディスクへ吐き出しとけばいいんです。

仕事はコンパイルまでで終わりだし、論文や文献の実証実験にもなって一石二鳥ですね。

＃一応「皮肉」で書いたつもり。OODBの利点を熱く語る人がいないとネタになっちゃうなぁ。
0228NAME IS NULL
垢版 |
05/02/21 17:13:33ID:Cc0+reOg
>>227 素敵なレスです。皮肉でなく。でもここだけは納得できません。
>SQLなんてコンピュータの都合で産まれたもので
SQLは論理式(まがい)です。オブジェクトを認識できるものが
論理から超越していることはあり得ません。
あなたの文章はしっかりしていますし、十分に論理的です。
0229NAME IS NULL
垢版 |
05/02/21 23:57:01ID:???
プログラムなんてデータのおまけ
0230NAME IS NULL
垢版 |
05/02/22 01:00:53ID:AhjHU21x
ミドルウエアの適用というのは多分にイマジネーションの世界だと思うんだけど、
やっぱり現時点では具体的に使えそうな業務というか適応分野があまり見当たらないよ。
（別部署のシステムでGemStone＋Smalltalkというシステムが1つあるけど、必然性を感じない）

それこそかつてのJavlinのようなEJBキャッシュみたいなニッチなところ（業務そのものの
データではなく、極めて基盤的なところ）にしか入り込めないという印象。

逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。
0231NAME IS NULL
垢版 |
05/02/22 18:01:16ID:???
>>225 >>227 >>228 >>229
オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。
SQLは集合の性質を記述するもの(内包的な定義)。
0233NAME IS NULL
垢版 |
05/02/23 01:22:10ID:???
>>225 商用システムでオブジェクトという概念を最初に持ち出したのが
システム38ですね。良かれ悪しかれ興味深いマシンでした。
0234NAME IS NULL
垢版 |
05/02/26 23:32:58ID:ZSke6ZFq
いろいろ異論はあろうが、ざっくりと「オブジェクト＝データ＋手続き」と定義する。

データについては、表現方法を妥当なレベルで共通にできる。
しかし手続きは、言語や処理系によってその表現は異なる。なかなか共通させることはできない。

「オブジェクトの表現形式」を標準化し、それをいろんな処理系からアクセスできるようにする作業が必要になる。
で、それは技術的には可能だ。
だが実際問題としてそこまでやる必要性が薄い。

単にオブジェクトデータベースを使うだけならいつでもできるが、
広い普及はまだまだ無理な状況にある。
0235NAME IS NULL
垢版 |
05/02/28 02:20:11ID:bYwMEZoh
BFS1.0やWinFSってRDBだよねぇ。OODBがFSになるのはいつの日か・・・
0236NAME IS NULL
垢版 |
05/03/02 00:32:49ID:???
OODBなファイルシステムっていまいちイメージがつかめんが、
Newtonのsoupとか、BTRONみたいなものかな？
0237NAME IS NULL
垢版 |
05/03/20 23:15:49ID:2uyd6Lyh
>> 234
データはオブジェクトごとに異なりますが、手続きは変わりませんよね。
オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。
また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、
むしろ手続きは永続化対象外でであるべきかと思います。

データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル
モデルに変換するひつようがないのであれば価値があると感じます。
0238NAME IS NULL
垢版 |
2005/04/02(土) 11:19:43ID:???
RDBMSで現実的なシステムを組むために
ストアドとかトリガみたいな機能が必要になったことが、
データと手続きが不可分であることを表していると思うのだが
0239NAME IS NULL
垢版 |
2005/04/04(月) 17:07:52ID:???
久々に書きこもう。

>>238
実装(プログラミング)のためにはそうした方が便利という面はあると思う。

だけど実装のために必要になったデータ(ループ変数とかフラグとか関数間受
け渡しための変数とか)と、業務で必要なデータ(顧客名とかIDとか単価とか)
は概念上別なものとして認識するのが自然だと思うけど。

OOな人は何故か「とにかくプログラム上は一緒なんだから」という考えのよう
な気がして不思議。

OOな人の目的ってやっぱりプログラミング?
0240U ◆CZtFsGiu0c
垢版 |
2005/04/05(火) 16:06:19ID:???
>>239
よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに
違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって
OODBを使いたがるとは限らないよ。
0241NAME IS NULL
垢版 |
2005/04/05(火) 17:28:25ID:???
>>240
ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

で、私は「永続化すべきデータに違いはない」とまるっきり区別しない事に、
違和感を感じていると書いたつもりです。
(この引用の仕方はU ◆CZtFsGiu0cさんの意図とは違っているかもしれません)

あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。

このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん
ですが。
0242U ◆CZtFsGiu0c
垢版 |
2005/04/05(火) 17:57:39ID:???
>>241
>ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。

>あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。

これは、「インピーダンス・ミスマッチ」の一言につきると思います。
設計したモデルをデータストアの都合で崩さなければならない、ということに
不満がありますね。

それから細かいことを言うと、データストアがOODBでない場合はカプセル化を
破るか永続化するデータを持つクラスが永続化の手段を知っている必要がある
ので、それはあまり歓迎できないと言うのはあります。

>しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。

合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
壁があるからなんとかできないか、と考えるのは自然ではないですか?
0243NAME IS NULL
垢版 |
2005/04/05(火) 18:45:37ID:???
>>242
> よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
> すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。

データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。

> 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
> 壁があるからなんとかできないか、と考えるのは自然ではないですか?

プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。

「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。
0244U ◆CZtFsGiu0c
垢版 |
2005/04/05(火) 19:28:39ID:???
>>243
>データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。

うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
当たり前だと思うけど、具体的にはどういうことですか?

>プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。

「顧客との意思疎通」はともかく、保守・運用やアドホックなデータ検索に
関しては今のOODBはダメダメですよ。それに関する認識はここにもさんざん
書きました。だからこそ、ObjectCacheやCacheに期待するところがあるん
ですけどね。

>「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。

もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
ことしか考えてないってことないですか? プログラムの保守についてはどう
思ってますか? データベースはシステムの一部にしか過ぎないんですよ。
0245NAME IS NULL
垢版 |
2005/04/06(水) 15:26:15ID:???
>>244
> うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
> 当たり前だと思うけど、具体的にはどういうことですか?

>>239で書いたようなことです。
「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。

> もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
> ことしか考えてないってことないですか? プログラムの保守についてはどう
> 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。

保守では有りませんが、DBMSの販売に昔かかわっていた者です。

DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。

・1つのDBに複数のプログラムがアクセスする場合が非常に多いこと
・システムの稼動に従ってデータ資産が増えていくが、その構造は簡単には変えられないこと
・CPUの速度よりもディスクの速度の方が圧倒的に遅いこと

プログラムだってシステムの一部に過ぎません。しかし「『一部』同士だから
検討の優先順位は同等だ」ということにはならないでしょう。
(無論個別の事情によってはいろいろと程度が変わってくると思いますが)

以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと
思います。
0246U ◆CZtFsGiu0c
垢版 |
2005/04/06(水) 20:17:50ID:???
>>245
>「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。

そういうことですか。実装上必要な揮発性のデータを永続化するなんて
ありえない、というか「データと手続きが不可分」と言う言葉を曲解してる
ように思います。

>DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。

特に反対することはないんですが、やはり誤解されていると思います。
OOでやってもエンティティはフローズンスポットになるのでそんなに
変更は入りませんし、既存のシステムは当然考慮しますよ。
0247NAME IS NULL
垢版 |
2005/04/07(木) 11:33:07ID:???
つかってはみたが・・・

なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・
まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・
0248NAME IS NULL
垢版 |
2005/09/17(土) 05:08:39ID:???
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試してみたらなかなか使いやすかった。
でも誰も使ってない予感
0249NAME IS NULL
垢版 |
2005/09/19(月) 07:51:19ID:C0eamAh/
で、複雑で大量の事象と空間をシミュレーションするのに
今現在はどの組み合わせのシステムがベストなの？
0250NAME IS NULL
垢版 |
2005/09/19(月) 07:55:19ID:C0eamAh/
多種多様のドキュメントを管理するには何がベスト？
業務処理するには何がベスト？
0251NAME IS NULL
垢版 |
2005/10/10(月) 01:31:00ID:+XVZSTvE
ObjectStoreは，かつてのOO指向のイメージからリアルタイムデータ処理へと変貌した。
0252NAME IS NULL
垢版 |
2005/11/13(日) 10:27:14ID:???
たとえば「注文」オブジェクトがあるとする。

注文番号
注文先
商品
単価
個数
消費税額

みたいなオブジェクトだとして。RDBMS だと、注文先番号 や 商品番号で
マスタとリレーションするよね。

O/R マッピングだと、マスタとジョインした結果を格納する、ってことができて、
RDBMS におけるメリット（マスタに変更があった場合、オブジェクトにもその
変更が反映できる）を受けられる。

OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに
変更があったらどうするんだろう？
0253NAME IS NULL
垢版 |
2005/11/13(日) 17:50:39ID:???
マスタデータを表すオブジェクトを更新するだけじゃないの？

注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト
0254NAME IS NULL
垢版 |
2005/11/13(日) 18:45:27ID:???
ということは、注文オブジェクトの方には、商品マスタオブジェクトのキーを保持
するってこと？

注文番号
注文先キー
商品キー
単価
個数
消費税額

って感じ？ これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。
0255NAME IS NULL
垢版 |
2005/11/13(日) 20:49:01ID:???
キーっつうか、マスタオブジェクトへのリファレンスだろ？保持するのは。
0256NAME IS NULL
垢版 |
2005/11/14(月) 01:37:46ID:???
ごめん。いまいちイメージがわかないや。

具体的にいうとリファレンスって何を保持するの？

public class Order {
　int OrderNo;
　Comany OrderCompany;
　Product OrderProduct;
　BigDecimal UnitPrice;
　int Quantity;
　BigDecimal Tax;
}

ってのを当初考えてたんだけど、これじゃ駄目だよね？
0258NAME IS NULL
垢版 |
2005/11/15(火) 22:52:49ID:???
それがまさにOODBってことなんだと思ってたんですが。
使ったことねえものわがらん。
0259256
垢版 |
2005/11/15(火) 23:26:19ID:???
当初それで考えてたんだけど、たとえば Product.Name が変更された
とするよね、永続化されてる Order クラスには、それがわからないと
思うのですよ。

と思ったんだけど、永続化されるのはあくまで Product クラスの参照であって、
Product クラスの変更は自動的に Order クラスにも伝播するってことかな？

XML への永続化とかだと、そうはならないんで、すっかり誤解してました。
0260NAME IS NULL
垢版 |
2005/11/16(水) 13:30:38ID:???
クラスという言葉はまぎらわしいからオブジェクトと言ってくれ。

実装によって細部は異なると思うけど基本的には
productオブジェクトもorderオブジェクトも、
どちらも永続化されていて、永続化されたDBの中で参照関係が
保持されていると考えるのが普通じゃないかと。
0262NAME IS NULL
垢版 |
2006/04/04(火) 11:09:47ID:???
>>259
それはヤバイ。製品仕様が変更になって、商品名が変わったときに、
以前に受けた注文の商品名が変わってしまうと、商売上、会計上
無茶苦茶になる。

業務知識に依存で、参照を持つ方法も取れるし、オブジェクト自体を持つ
事も出来るし、必要な項目だけコピーする事も出来る。

どれを選ぶかは、業務次第。
0264NAME IS NULL
垢版 |
2006/06/03(土) 17:13:50ID:???
db4oのアンケート答えたら本が当った、わーい。
実はまともに触ったことないけど、
届いたらじっくり読んで遊んでみることにするよ。

英語苦手だけど。
0265NAME IS NULL
垢版 |
2006/10/01(日) 16:47:44ID:raj0JmDs
Ｊ○１なんて、変更多かったりいろんなベンダー絡んでくるＷＥＢ系噛んでくると当然だが、まったく使えない。
「どうやって直しゃいいーの？やりようねーよ。」って・・・hahaha
でもって塩漬け
0267NAME IS NULL
垢版 |
2007/01/13(土) 22:57:22ID:CL7OUlxj
OQLを使える組み込み可能なOODBって何がある？
0268NAME IS NULL
垢版 |
2007/01/17(水) 00:28:55ID:???
ラムダDBとか。つかちょっとは調べろや
0269NAME IS NULL
垢版 |
2007/01/17(水) 16:54:49ID:???
>>268
すまん
Javaのやつを探していたのでスルーしてた
0270NAME IS NULL
垢版 |
2007/01/17(水) 16:58:21ID:???
db4oがOQL使えれば最高なんだがな・・・NQってなんだよorz
コンパイル時にチェックできてもポータビリティがないじゃないか
0272NAME IS NULL
垢版 |
2008/06/22(日) 19:52:26ID:???
db4o、色々実験してみて気に入った。
仕事でも趣味でも使ってる人います？
0273NAME IS NULL
垢版 |
2008/06/24(火) 01:16:29ID:hnzrfZsh
>>272

趣味で弄ろうとしてて苦戦中。
Javaで書いてるんだけどオブジェクトをsaveしたりopenしたりする専用のDAOクラス作った方がいいのかな？

0274NAME IS NULL
垢版 |
2008/06/24(火) 02:45:42ID:???
>>273
本格的なプログラムの場合はDAO作った方がいいよ。
海外だと弄ってる人多そうだけど、日本は少ないね。

たしかリコーと提携して何かやるとかって話があったけど、
どうなったんだろう。
0275NAME IS NULL
垢版 |
2008/06/25(水) 08:20:07ID:TGcEK7R9
>>274

中国が積極的みたいだけど日本はね…

リコーは開発案件で積極的に導入してるぐらいだと思うけど。

しかしよくエンタープライズで使う気になるよなぁ
0276NAME IS NULL
垢版 |
2008/06/25(水) 17:34:38ID:???
日本は盛り上がらんね。
日本語の開発者向けフォーラムもさっぱりだし。

リコーはエンプラじゃなくて組み込みじゃないかな？
0277NAME IS NULL
垢版 |
2008/06/25(水) 19:43:52ID:TGcEK7R9
>>276

そうそう、サンプルが少ないから未だにDAOからオブジェクト追加出来ない俺…orz

組み込みなんだ？

自社製品になら納得。

0278NAME IS NULL
垢版 |
2008/08/12(火) 23:38:20ID:???
>>277
サンプルってpdf読んだ？pdf＋あっちのフォーラムで解決出来るよ。

Dao作ってる人はQBE?NQ?SODA?どれベースにした？
ソートとか考えるとSODAしかないのかな・・・
0279NAME IS NULL
垢版 |
2008/08/12(火) 23:53:41ID:???
って1ヶ月前が最終レスか・・・やっぱSODAに行き着いたら離れてくか
0280NAME IS NULL
垢版 |
2008/08/13(水) 07:50:09ID:???
最近さっぱりいじってないけど、俺はNQ
でもSODA併用にすると思う
NQを完全に捨てた場合は、離れたくなる気持ちも解る…

実はQBEが一番好みなんだが、単純なクエリにしか使えない
0281NAME IS NULL
垢版 |
2008/08/17(日) 13:37:16ID:???
>>280
全部のエンジン対応のBaseクラス実装してみた。
・・・Update、Deleteがスマートになった位。

>実はQBEが一番好みなんだが、単純なクエリにしか使えない
QBEは完全におまけだね、用意した意味がわからないレベル。
NQ→SODAも怪しい所があるらしいし。

・・・やっぱりH2＋O/Rでいいやｗ
0282NAME IS NULL
垢版 |
2008/09/04(木) 06:17:39ID:Jasyu6Tw
Google Chrome + Google Gears 大人気だなｗ

Object Store Personal Edition で時代を切り開こうとしてたJava厨涙目ｗｗｗ
0283NAME IS NULL
垢版 |
2008/11/09(日) 03:10:17ID:gH6xlPae
ちと質問。
OODBならGBのファイル管理も余裕ですよ！と謳っているけど何で？
DVDから直抜きしたエロ動画コレクションをOODBで管理すると仮定して
神イグザンプルを教えてエロイ人！！！
0284NAME IS NULL
垢版 |
2008/11/09(日) 08:58:10ID:???
1件のデータが非常に大きいとしても、件数が数千、数万ならOODBでも余裕じゃね？
RDBじゃ無理とか言ってなければ別に嘘じゃない。
0286NAME IS NULL
垢版 |
2010/02/27(土) 02:58:52ID:???
KVSよりかはこっちにがんばって欲しいもんだが…
0287NAME IS NULL
垢版 |
2010/04/23(金) 08:21:04ID:iFVUkXwP
まだOODBって業務で使えるレベルではない？
0289NAME IS NULL
垢版 |
2011/01/10(月) 22:42:41ID:PKlMUoys
O/RマッパーとかいうクソみたいなFWが流行っちゃってるから
とっととOODBをもっと広めろやアホども。
0291NAME IS NULL
垢版 |
2011/01/21(金) 00:26:36ID:???
「またおまえか」
じゃねーよ。
しっかり広めろ。
0292NAME IS NULL
垢版 |
2011/01/21(金) 11:47:08ID:???
よし>>２９１に任せた！
0293NAME IS NULL
垢版 |
2011/03/16(水) 12:29:11.83ID:+4v+dlKX
PHPで使えるSQLiteのような手軽なOODBない？
0294NAME IS NULL
垢版 |
2011/03/26(土) 19:51:40.99ID:???
継承できればオブジェクト指向というのは違う。
メッセージを送ってメソッドを呼び出せないなら
オブジェクト指向型じゃない。
0295NAME IS NULL
垢版 |
2011/05/24(火) 23:55:55.53ID:xKicDgVR
>>294
だからSQLiteのような手軽なOODBが無いかと言ってんの。
OK？
0296NAME IS NULL
垢版 |
2011/05/26(木) 06:07:49.44ID:???
ないない。
無いからお引き取りください。
0299NAME IS NULL
垢版 |
2016/01/07(木) 00:20:03.13ID:PXFmI/6O
今までに無い全く新しい手法！
http://goo.gl/ogJo8a
0301NAME IS NULL
垢版 |
2017/04/15(土) 06:27:52.60ID:PAxoNq0R
realmはここでいうオブジェクトデータベースになる？
0302ich1
垢版 |
2017/04/21(金) 16:36:29.64ID:R/eXxgbc
https://goo.gl/q9Ml0S
これは嘘でしょ？本当だったら落ち込むわ。。
0303NAME IS NULL
垢版 |
2017/12/29(金) 11:40:58.19ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

66CFHAV81O
0304NAME IS NULL
垢版 |
2018/02/14(水) 13:34:08.01ID:???
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
0305NAME IS NULL
垢版 |
2018/09/07(金) 21:46:35.74ID:u0dGdBIY
まだあったのか
ここでバトルしたのも15年も前か
0308NAME IS NULL
垢版 |
2021/01/10(日) 04:12:43.35ID:???
db4oはどーなったんだ？
0309NAME IS NULL
垢版 |
2023/02/26(日) 11:06:17.37ID:???
まだあったのか
あと2年でRDBはOODBに置き換わると30年前に聞いたが
かつての推奨者はどう総括してくれるのかね
KVSやNoSQLはにぎやかだけど
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況