19: OODB - オブジェクト指向データベース (305)
2ちゃんねるブックマークは2ちゃんねる(2ch.sc)のログをブックマーク出来るビュアーです。


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

【pc】
pp 

1 名無しさん@お腹いっぱい。
03/07/02 23:49 ID:L/c0q833

javaの盛り上がりでOODBに移行していくと思いきや
O-Rマッピングかよ!
語りやがれ!

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



【pc】





スレッドの最初から全部を見る 人気スレッドリスト

外国語アレルギーの方に朗報!
2ちゃブで外国語を楽しく学ぼう!





2 名無しさん@お腹いっぱい。

sage

03/07/03 00:04 ID:???

またくそスレ立てやがったか・・・

3 名無しさん@お腹いっぱい。
03/07/03 00:15 ID:UvAyQVVL

商用OODB

Objectivity
http://www.objectivity.com/

ObjectStore
http://www.odi.com/

GemStone
http://www.gemstone.com/

Versant
http://www.versant.com/


4 千葉糞DB連盟
03/07/03 00:43 ID:???

ほっとけほっとけ。

どうせこんなスレすぐにdat落ちするんだからよぉ

5 名無しさん@お腹いっぱい。

 

03/07/03 01:09 ID:???

OODBとRDBの違いを教えて。
OODBは継承ベースデータベースって事?

6 名無しさん@お腹いっぱい。
03/07/03 01:21 ID:???

ORDBっつーのもあった気がする

7 名無しさん@お腹いっぱい。
03/07/05 15:41 ID:???

XML-DBじゃダメかい?

8 名無しさん@お腹いっぱい。
03/07/06 00:27 ID:???

6
PostgreSQLのことだっけ?
テーブルの継承とかできるっていう。

使うか? あれ。

9 名無しさん@お腹いっぱい。
03/07/06 02:11 ID:???

7
面白いけど重すぎ。

10 7
03/07/07 00:50 ID:???

9
重いのか。しかし盛り上がらないなぁ。
まぁOODBってDBを頻繁に扱う人間にとってはどうでもいい存在なんだろうな。
俺はDBドシロウトだからむしろ興味深いんだが。


11 名無しさん@お腹いっぱい。

さげ

03/07/11 21:57 ID:???

Java用のOODBで実績あるのって何?

12 名無しさん@お腹いっぱい。
03/07/12 00:34 ID:E4gmilr7

オブジェクト指向データベースの事が理解できません。
なんか便利そうなのは分るけどリレーショナルとどこが違うのか
やさしく叱りながら教えてください。

13 名無しさん@お腹いっぱい。
03/07/14 16:26 ID:Cb391GNe

「オブジェクト指向データベース」定義が解説書によって
異なっていたりするのには混乱した。
OMGのDB版、ODMGが公開しているのが正しい定義ということでよろしい?

14 名無しさん@お腹いっぱい。
03/07/15 10:24 ID:???

OracleはOODB?

15 名無しさん@お腹いっぱい。
03/07/16 00:07 ID:pi7rfdPX

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 名無しさん@お腹いっぱい。
03/07/16 15:00 ID:l8xjyibq

うんこーーーーーーーーーーーーー

17 名無しさん@お腹いっぱい。
03/07/19 00:14 ID:OyiHRbbd

OODBっていうくらいだから、継承ができんのかな?
参照項目をSQLで結んでやんなくてもいいとか?
開発するんだったら楽チンそうですね

18 あぼーん

あぼーん

あぼーん

あぼーん

19 名無しさん@お腹いっぱい。
03/07/20 04:40 ID:Fs8ijVwW

テストデータ作成とか、データをCSVで作ったり、データのローディングしたり。
こんな作業はどうするの?

20 名無しさん@お腹いっぱい。
03/07/20 12:08 ID:???

オブジェクトリレーショナルデータベースと

オブジェクト指向型データベースの違いがわからん。


PostgreSQLはリレーショナルのほうに相当するらしいが。

21 名無しさん@お腹いっぱい。
03/07/21 01:32 ID:???

20
ObjectStoreについて調べてみれ

22 名無しさん@お腹いっぱい。
03/07/24 06:35 ID:???

遊べるフリーのOODBってないよね?
Zopeが感覚的にかなりOODBに近いと感じたんだけど...

23 あぼーん

あぼーん

あぼーん

あぼーん

24 名無しさん@お腹いっぱい。
03/07/27 01:26 ID:ww4gq4YT

オラクルのオブジェクトリレーショナルは、是非使いたいが。
実務での話になると、強引に進めれる相当な強権を持ってるか、
コケてもOKなしょぼしょぼの自社内システムでしか作れないな。

まず、あれを使えば、開発側からブーイングが出るやろうし、
なにより、
「速度は、保証できんねんな?」
と迫られれば、
「普通で行きます。」
と答えるしかない。
「速度は、保証できるんか?」
やって。普通のDBでも投げるSQLで全然速度は変わるっちゅうねん。畜生。
お前らが、印刷したらB4一枚埋まる様な巨大なSQLを投げるから遅いねん。
誰がメンテすんねん。あんなSQL。

だれか、オラクルのオブジェクトリレーショナルで、DBを構築してしまった
人いる?実務で。

25 名無しさん@お腹いっぱい。


03/07/27 20:41 ID:???

5
OOのシステムでRDBを使うと、オブジェクトの状態を表形式に変換して保存しなければなりませんが、
OODBはオブジェクトの状態をそのまま永続化できます、属性とか関連とか。



らしい。

http://www.ogis-ri.co.jp/otc/hiroba/technical/objy/step1.html

26 名無しさん@お腹いっぱい。
03/07/27 21:09 ID:U28p0G+i

不勉強ですまんが、OODBって、シリアライズして普通のファイルに保存するのに較べて何か利点あるの?
永続化したいオブジェクトをHashMapに入れて一気に直列化すればトランザクションの
まねごともできるから、あんまOODBの必要性を感じない今日この頃。

27 あぼーん

あぼーん

あぼーん

あぼーん

28 名無しさん@お腹いっぱい。
03/07/27 21:41 ID:???

26
ロックとかアクセス権限とか、かなぁ。

29 名無しさん@お腹いっぱい。
03/07/27 23:14 ID:KTLjujEW

26
DBのなかでもオブジェクトには生きていてほしいんです。

だからトリガやアサーションなんかも。

30 あぼーん

あぼーん

あぼーん

あぼーん

31 名無しさん@お腹いっぱい。
03/07/28 04:10 ID:???

>30
肛門だったらアナルじゃなくてアヌスだろ、馬鹿が。
アナルは「肛門の」という形容詞だ。
他にもオーラル(口の)マニュアル(手の)と色々あるがな。



と宣伝コピペにマジレスしてみる。
しかもこんな時間に。


32 名無しさん@お腹いっぱい。
03/07/28 05:06 ID:???

徹夜中。
OODBって言語に依存せざるをえないと思うんだけど、言語非依存の実装やってる奴ってないのかな。

たとえばC++なんかはリフレクションもないわけで、OODBに格納するのはやりづらそうなんだが...
メモリ内容をそのまま固めたんじゃ、他の言語からアクセスできないしね。

そこらへん、どうにか解決してる実装があったら教えて欲しいです。


33 名無しさん@お腹いっぱい。
03/07/28 12:11 ID:Whoi2Qyb

26

例えば,ノードがたっくさんある木構造のオブジェクトで,
どっかのノードを一つだけ update したばあい,

* 直列化 : 木構造全体を保存する
* OODB : 修正したノードだけ保存する

と,なるのではないかな.





34 あぼーん

あぼーん

あぼーん

あぼーん

35 あぼーん

あぼーん

あぼーん

あぼーん

36 あぼーん

あぼーん

あぼーん

あぼーん

37 名無しさん@お腹いっぱい。
03/07/30 02:17 ID:lWu+Xd4c

33
それって、
class Person { String FirstName; String LastName; }
っていうクラスのオブジェクトでLastNameのみを更新した場合に、
Personのオブジェクト自体は直列化しなおさないってこと?

38 あぼーん

あぼーん

あぼーん

あぼーん

39 名無しさん@お腹いっぱい。
03/07/30 12:20 ID:???

37
まあ、イメージとしてはそんなもの。
実際は仮想メモリのページ単位だったりするんだけど。

40 名無しさん@お腹いっぱい。
03/07/30 17:32 ID:???

39
それはOODBじゃなくてObjectStore。

41 名無しさん@お腹いっぱい。
03/07/30 20:39 ID:???

40
他のアーキテクチャで代表的な実装ってどんなのがある?

42 名無しさん@お腹いっぱい。
03/07/30 22:09 ID:???

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
このあたりからたどって参考にしてみて。


43 あぼーん

あぼーん

あぼーん

あぼーん

44 あぼーん

あぼーん

あぼーん

あぼーん

45 ぼるじょあ </b>◆ySd1dMH5Gk <b>

(^^)

03/08/02 04:54 ID:???

     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

46 山崎 渉

(^^)

03/08/15 23:08 ID:???

    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

47 名無しさん@お腹いっぱい。
03/09/04 02:34 ID:???

OODB復活の先鞭をつけたSybaseの話題が無いのは何故なんだ?

48 名無しさん@お腹いっぱい。
03/09/04 07:55 ID:qJ02ntW8

SybaseにOODBの製品なんてあったっけ?

49 名無しさん@お腹いっぱい。
03/09/04 13:37 ID:E400tBTc

何故JASMINEの話が出ないんだ?

50 名無しさん@お腹いっぱい。
03/09/04 13:54 ID:???

49
あなたを待ってたので

51 名無しさん@お腹いっぱい。
03/09/19 14:39 ID:9kTuVrlL

いたすかあげ

52 名無しさん@お腹いっぱい。
03/09/25 03:01 ID:ma4FuxQc

codqlie -silent でお願い.

53 名無しさん@お腹いっぱい。
03/09/25 19:25 ID:IZpPFNOX

OODBって実績としてはどうなんだ?



54 NAME IS NULL
03/11/05 22:30 ID:QWIrGJf0

c++対応のフリーのOODBMSない?

55 NAME IS NULL
03/11/08 16:44 ID:???

jasstop -kill

56 NAME IS NULL
03/12/03 12:20 ID:JF3cjEmh

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 NAME IS NULL
03/12/05 13:27 ID:???

すいません、JavaベースでフリーなOODB、Ozoneの評価はどんなものなんでしょう
使っている人います?
http://www.ozone-db.org/frames/home/what.html

58 名無しさん@お腹いっぱい。
03/12/09 11:26 ID:9pNPj1xu

56
> またOODBでは開発言語(JavaとかC++とか)でデータベースを操作できるので、SQLを覚えなくてもよい。

OODBでもQuery Languageは必要では?
上は更新系のことだと思うけど。


59 NAME IS NULL
03/12/09 15:48 ID:TR0CCqSo

58
必要ないよ。

60 名無しさん@お腹いっぱい。
03/12/09 16:37 ID:9pNPj1xu

59
サンプル教えて。使ったことないせいか、「query(条件文の羅列)」みたいな
のは必要だと思い込んでた。



61 NAME IS NULL
03/12/09 17:04 ID:SwlxuIVz

それは、ORDB

サンプルってか、new foo(bar,bu,bi)でインスタンスの生成
foo.updateで更新、foo.siraizeで格納。
こんなイメージで扱えるのがOODB

databaseobject.select(Query)てなイメージが有るの?

62 NAME IS NULL
03/12/09 17:23 ID:???

query(条件文の羅列)

63 名無しさん@お腹いっぱい。
03/12/09 17:56 ID:9pNPj1xu

61

一回格納したインスタンスはどうやって取り出すの?

64 NAME IS NULL
03/12/09 18:14 ID:9ALHY4AH

63
OODB使え。嘘だと思ってるのか、馬鹿か、どっちかだな(w

65 NAME IS NULL
03/12/09 18:32 ID:???

しらいぜ

66 NAME IS NULL
03/12/09 21:52 ID:???

"> 59
わざわざ2chの書き込みのために使ってみる気はしません。
ちなみに私が「嘘だと思っている」のか「馬鹿」かどっちだと思いますか?

67 66
03/12/09 21:58 ID:???

すいません。ずれました。
66は64へのレスです。

61であがっているのは更新系だけなので、参照系はどうなのかなと。
SQL99で定義されてない構文だからQLじゃない、という意味じゃないですよねぇ。
大昔VERSANT(1.1の頃)を触ったときにはQLらしきものがあったんですが、今はもう無くなったんですかね。
でもどうやって無くなったんだろう?

#こんな話をするのは10年前のNifty以来だ(笑)

68 66


03/12/16 18:14 ID:???

1週間止まったな。
61,62,64の人がOODBを熱く語ってくれないかな。


69 NAME IS NULL
03/12/18 12:28 ID:uB5193t8

では、タダで使えるおすすめのOODBをおしえてちょ?

70 NAME IS NULL
03/12/18 22:52 ID:???

69
Ozone

お勧めかどうか知らないが、一応フリーでOODB。

71 NAME IS NULL



04/02/11 13:12 ID:???

Tamino の情報求む!

72 NAME IS NULL
04/04/15 20:42 ID:???

Cache のシングルユーザーライセンス無償版てのではいかんの?

73 NAME IS NULL
04/04/15 22:54 ID:???

Cache'ってホントにOODBなのか?

74 NAME IS NULL
04/05/22 09:56 ID:???

FramerD って使っている人いませんか?

75 NAME IS NULL
04/05/22 21:06 ID:Bbf7GDLk

ム板にあったリンク集だけれど、
何種類かあるのね。フリーなOODBも。
誰も使ってないのかな?
http://www.linas.org/linux/db-non-sql.html

76 NAME IS NULL
04/06/07 22:19 ID:???

67
Zopeしか知らないけれど、
格納とか取り出すって考え方がそもそも無い気がする。
インスタンス作ったら、それがそのまま永続化されてたような。

77 NAME IS NULL


04/06/08 10:14 ID:???

半年振りにレスがきて懐かしい。
76
> 格納とか取り出すって考え方がそもそも無い気がする。
> インスタンス作ったら、それがそのまま永続化されてたような。
ということは、アプリケーションは将来にわたって参照する可能性のあるオブ
ジェクトを、あらかじめ全てハンドリングしているということ?


78 76
04/06/08 23:47 ID:???

ごめん、俺バカなんで、もうちょっとバカにも分かるように書いてちょうだい(´・ω・`)

79 NAME IS NULL


04/06/09 10:47 ID:???

78
すまん、先走りすぎた。
インスタンスを作るとそのまま自動的に永続化されて、後からそのインスタン
スを参照すると自動的に取り出される、と考えて良いんだよね?

立ち上がったアプリケーションがあるインスタンスを参照するためには既にポ
インタを持っているか、ポインタをたどればそのインスタンスへ行き着く、と
想像しているんだけど。

そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
ているインスタンスはどうやって取り出すんだろうか?

そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
装もあるし、MDA絡みでも似たような宣言的構文ができて、「サーバにリクエス
トを出す→目的のものを受け取る」ということを昔からやってきてるはず。

ところが上の方のレスだと「OODBならそんなの必要ないじゃん」ということら
しいので、もっと詳しく聞きたかったんだけど。

Query Languageが無いと「suspendとdumpが賢くなって、セーブ機能を簡単に
実装できます」というような、stand aloneアプリケーション組み込み用のDBに
しかならないような気がする。


80 NAME IS NULL
04/06/09 22:37 ID:???

79
ZODBって、Python OrientedなDBっぽいんだけれど、
rootって一番基本になるオブジェクトがあって、
そこから、rootオブジェクトに対して、連想配列みたいな感じで
DBに入ってるインスタンスにアクセス出来るっぽい。

データを格納して検索してっていうよりも、プログラムそのまま入ってるっていうか、
シリアライズ不要で、生のオブジェクトをそのまま格納する場所って感じ?

なんか、自分でも良くわかんなくなってきた。

Cacheなんかは、SQLも使えるらしいし、全然違う物なのかな?
ZODBを使用しているZopeを使用しているだけのユーザなんで、
難しい事分からなくてごめんよ。

81 NAME IS NULL
04/06/16 23:11 ID:???

79
OQLってあるみたいだねえ。詳細知らんけど。
http://www.iioss.org/Manual/dbf/dbf9.6.html

82 NAME IS NULL
04/07/03 10:34 ID:kQUC+wZT

Matrix
http://www.matrixone.com/

は独自のQLを使っている。
が、速度を無視してくれるなら提供されてるJavaのAPIを使えば
その独自QLを使わなくてもすべてJavaでいける。
オブジェクトの取得はインスタンス化する際に主キー+αを渡すようなイメージ。

83 NAME IS NULL
04/07/15 22:07 ID:9ZnW1i7A

79

昔、Objectivityを使ってました。
複雑な構造を持つデータと、頻繁なデータの入れ替わりには
ODBMSしかないのでは。
速度がそもそもORDBMSと違います。
イリジウム衛星の軌道制御にも使われていたらしい。

>そうすると他のアプリケーションが作ったインスタンスや、初期DBに登録され
>ているインスタンスはどうやって取り出すんだろうか?

DB初期化時にルートのコレクション・オブジェクトを得るのでそこから辿って行きます。
ちなみに、名前でオブジェクトを関連づけたりできます。

> そのためにCODASYLのFIND文(?)とかSQLやOQLみたいな規格もできたし、独自実
> 装もあるし、MDA絡みでも似たような宣言的構文ができて、「サーバにリクエス
> トを出す→目的のものを受け取る」ということを昔からやってきてるはず。

そもそも、DBのクラスライブラリーに強力なコレクション・クラスがあるので
その検索メソッドを呼び出すなり、そのクラスを使用して強力なコレクション・クラスを作れば
SQLみたいに、文を生成する必要はないです。
ただ、他の言語バージョンに同様のクラス・ライブラリーが移植されていなければ諦めるしかないです。


84 NAME IS NULL


04/07/16 12:04 ID:???

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 NAME IS NULL
04/07/16 12:18 ID:???

84
83じゃないけど

> そうしたものが沢山出来てきて、管理するのが面倒だから代わりにDBMSがやっ
> てくれるんじゃないでしょうか。

> 自分でどのぐらい作らなきゃいけないかが論点ですね。SQLを組み立てるのと
> 比べてどのぐらい強力な機能で、どのぐらい簡単なんでしょうか。

そういうのがパッケージとして用意されていれば問題ない気がする。
そのパッケージがDBベンダーからそろって提供されれば今のRDBMSのように
なるだろうし、Javaで標準ができてCORE APIかJ2EEにでもなろうものなら、どの
ODBであろうとベンダーによって文法が変わったりとかせずに、それ以前にデー
タへアクセスするソースとかは一切変更しなくていいわけだし。

どっちの方向に行くのか俺には分かんないけどね。


> プログラムから呼び出す方法を考えるときに、未知の不定個のデータを扱う良
> い方法が無いこともあって、SQLをそのまま埋め込んでループでまわすなんて
> いう方法に落ち着いちゃったんでしょう。

RDBでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
してくれるから、そのままオブジェクト指向として使える。

ループで回すって言うなら、RDBに関係なくCOBOLでもそうじゃないのかな。


86 NAME IS NULL


04/07/20 15:03 ID:???

85
少し話題が他の方向へ行きましたが。

> そういうのがパッケージとして用意されていれば問題ない気がする。

> RDBでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> してくれるから、そのままオブジェクト指向として使える。

そうやって標準化/利用便宜のためのレイヤが重なってくるとすると、そのバッ
クエンドにある格納/トランザクション管理システムをRDBからOODBに移行す
るメリットはどの辺にありそうでしょうか。

> RDBでも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 85
04/07/20 22:40 ID:???

86

あんまり詳しくないんですが、


> そうやって標準化/利用便宜のためのレイヤが重なってくるとすると、そのバッ
> クエンドにある格納/トランザクション管理システムをRDBからOODBに移行す
> るメリットはどの辺にありそうでしょうか。

重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
私がここで言いたかったのは、どこを標準化するかというのがこれからの問題(焦点?)であって、
今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。

あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。

個人的には、RDBに限界を感じてますね。RDBはデータ構造が2次元ですが、階層的に持ちたいって思う事が
多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。
だからオブジェクトとかXMLとかがそのまま格納できりゃあいいんですが、現実問題として考えると・・・


> > RDBでもO/Rマッピングツール使えば勝手にList, Map, Iteratorから取得できるように
> > してくれるから、そのままオブジェクト指向として使える。
> List, Map, Iteratorそのほかが使えればオブジェクト指向的だと考えてよい
> んでしょうか。(この辺の判断基準は良く分かりません)

んー。違いますね。それはまた別問題ですね。
Listに格納されているクラスがオブジェクト指向設計されているかどうかは別の話でしょう。

項目50個あるからセットするコードを50行書いてとか自分でBeanをnewしてなんて書かなくても、今のO/R
マッピングツールの中にはそういうのを自動で勝手にやってくれて、Listで返してくれるものもあるよんって意味でかきました。
(マッピングツールが全部そうってわけじゃないけど。)

ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。


> 本題から離れた興味ですが、1回のQuery結果件数が多数になった場合、RDBで
> はResultの受け取りをStreamingすることになりますが、ORマッピングツール
> (やOODB)でも同様の動作になるんでしょうか。

やっぱそうじゃないんでしょうか? limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
(offsetとかもありましたっけ?)、そうじゃなけりゃくるくる回してるでしょう。

問題は、そのくるくる回す部分を「私がプログラミングする必要があるかどうか」じゃないでしょうか?


> #Listのノードを先へたどるときに、「未取得」と「最後」の2種類のステータスがあるとか。
> それとも全結果が確定してからList等をクライアントで受け取ることになるのでしょうか。

 さあ? OODBってのは誰が(どこで)やるのが一番ベストなんでしょう?

私としては、「私がコーディングする必要があるか否か」が重要であって、DBMSが担当しようと、
DBMS以外が担当しようと、速度的に同じであればDBMS内に標準化されていようがDBMS外で
標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。

次の問題としては、ベンダー(というか製品)によってアクセス方法に違いがあるってことですが(RDBでいうところのSQL)、
これは理想論なんでしょうかね? SQLが無い時代を考えたら進歩する可能性もあるのかもしれませんね。

#オブジェクト指向なら、継承で独自拡張路線?


88 NAME IS NULL


04/07/21 13:54 ID:???

87
> 重いかどうかとRDBとOODBをどう使い分けるかというのは別の話だと思いますよ。
> 私がここで言いたかったのは、どこを標準化するかというのがこれからの問題(焦点?)であって、
> 今の時点で、必ずしも今のRDBにおけるDBMSと同じ形態と決めつけるのはつまらないよんって事です。
>
> あとこれは同意見だと思いますが、RDBに適したものをOODBに無理矢理移行するのはナンセンスだと思います。

確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。
世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
便利」というのが分かりづらいです。

この手の話だとOODBの特徴について議論しているうちに「要は適材適所」とい
う落ち着かせ所が出て来てしまうんですが、それは初めから当然のこととして
わかっているわけで。

しかもOODBベンダ等は「ポストRDB」として売り出して「将来は入れ替わる」と
いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
しれませんが。

営業活動の結果としてこんなところで使われているという話よりも、OODBの性
質上こんな使い方が向いているという点が分かりやすく出てこないですかねえ。

最もそれをいうとRDBも別にユーザから「リレーショナルモデルが使いたい」
とか「SQLでコーディングしたい」なんて要望があるわけじゃなくて、クライ
アントサーバがブームになったときにRDBMSぐらいしかそれを実現する手段が
無かったから使われたんだと思いますけど。

> 個人的には、RDBに限界を感じてますね。RDBはデータ構造が2次元ですが、階層的に持ちたいって思う事が
> 多々あります。じゃあ正規化して別テーブルにすりゃあってごもっともなご意見が返ってきそうですが、頻繁に
> 変更されるのが当然という現在のビジネス速度に対応するには、正直つらいです。

そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
葉のアヤであって、別に2次元でモデル化しようというわけでもないし。

OODBでは「プログラム中の構造がそのまま格納できる」というのを売りにして
いますが、じゃあRDBでは「プログラム中で頻繁に使う2次元配列を簡単に格納
できる」のが売りかというと全然そんなこと無いし。

変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
ピンと来ません。

そりゃあコンパイルしてテスト通して納品しておしまいなら良いんですが、そ
れまでシステムが稼動して蓄積してきたデータ資産や他アプリケーションがあ
るわけで。

異なるオブジェクトモデル間をコンバートやラッピングする手法/ツールが出
てきてるんでしょうか?

しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。


89 NAME IS NULL


04/07/21 13:56 ID:???

87
長くなったので分割。

> ああ、ここで言っているListとかは、javaのcoreクラスです。念のため。

ごりごりプログラムしているわけではないので詳しくは分かりませんが、なん
となく理解できました。

> やっぱそうじゃないんでしょうか? limitとかtopとかキーワードをSQLに書けるRDB製品もありますが
> (offsetとかもありましたっけ?)、そうじゃなけりゃくるくる回してるでしょう。

limit等は最終的に返す個数の指定ですが、RDBなどでは例えば検索結果が100
万件あったら確定した結果が順次クライアントへ送られる、という意味で
「Streaming」と書きました。クライアントが1件目の結果を処理しているとき
はサーバは50万件目を探しているかもしれない。

> 私としては、「私がコーディングする必要があるか否か」が重要であって、DBMSが担当しようと、
> DBMS以外が担当しようと、速度的に同じであればDBMS内に標準化されていようがDBMS外で
> 標準化されていようがあまり重要でないと思います。あくまで「私としては」ですけどね。

私としては、システムというのは動かして使われるためのものなので、コーディ
ングの便宜よりもどういうアーキテクチャで動くのかとか、稼動させたときの
運用制限はどうなるのかという点の方を重視したいです。

実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
して動作するんだし。

#暑すぎて仕事がはかどらないくせに長文w。 2chに文字数制限があるのをはじめて知った。



90 NAME IS NULL
04/07/21 22:19 ID:???

88

> 確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
> なのかのイメージがつかめません。
> 世にでてから10年以上もたってるんだから、おおよそ「こんなところで使うと
> 便利」というのが分かりづらいです。

んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
分析・設計(モデリング)して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま(オブジェクトのまんま)格納
や抽出なんかができれば便利なわけです。だからOODBの登場ですよね。
別にCやCOBOLのようなオブジェクト指向言語でないもので開発を行うのであれば、OODBなんてまったく無意味でしょう。


> しかもOODBベンダ等は「ポストRDB」として売り出して「将来は入れ替わる」と
> いうノリで宣伝していたように思います。いつの間にか言わなくなったのかも
> しれませんが。

速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。

今はそれに変わって既存のRDBがオブジェクトもいけますよっていうORDBがでてきてますね。Oracleしかり、MSSQLしかり。
まあ、これからのもんでしょうけど。

91 NAME IS NULL
04/07/21 22:32 ID:???

88
ああ、長くなったので分割したら、後半がきえてしまった。orz



> そう、別テーブルにすりゃあ、と思ってしまいます。RDBが2次元というのも言
> 葉のアヤであって、別に2次元でモデル化しようというわけでもないし。

RDBは現実のモデルを正規化という手法によって2次元のテーブルを設計していくわけですよね。

システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
状態になったり、今まで必須だった項目がまったく不要になったり、、
結構頻繁にあるんですよねえ。

#うちの会社だけ?


> 変更が起こった場合、オブジェクト指向だと対応しやすいというのもいまいち
> ピンと来ません。

んー、オブジェクト指向だからってことはないのかもしれませんねえ。


> 異なるオブジェクトモデル間をコンバートやラッピングする手法/ツールが出
> てきてるんでしょうか?

O/Rマッピングツールでしたら、私のお薦めはこれ。
http://www.ibatis.com/common/sqlmaps.html


> しかし現実にはシステムの数だけDBが作られたりするので、モデルを変更する
> たびに全部丸ごと作り変えればよいという割り切りもありかもしれませんが。

仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は2つあります。
・一から作り直す。
・今のを修正して、無理にでも動かす。(もち問題先送り)
で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、


92 NAME IS NULL
04/07/21 22:38 ID:???

89
> 実際「OODB」ってのはインタフェースを提供するラッパーじゃなくて、実際に
> ディスク領域を確保してクライアントからのリクエストを受け付けるサーバと
> して動作するんだし。

別にJ2EEのようにインターフェイスだけ共通で定義されていて、実装は各ベンダーが
行ってもいいわけです。

私は
「この条件に従ってデータを取ってこい。それが仮に50万件あろうと、このソー
トキーに基づき41~60件目の20件だけデータを返せ。」
という命令がしたいだけ。


93 NAME IS NULL


04/07/23 12:46 ID:???

90
> んー。手続型からイベントドリブン、現在はオブジェクト指向言語が主流になってきてますよねえ。私はjava使ってますのでjavaで話を続けますと、オブジェクト指向
> 分析・設計(モデリング)して、システム開発するにあたり、何が問題かっていうと、データの格納なんですよね。インスタンスのまんま(オブジェクトのまんま)格納
> や抽出なんかができれば便利なわけです。だからOODBの登場ですよね。

あぁ、この辺の感覚が私とは違いますね。「プログラムの中にあるデータを格
納したい」とは考えないです。だってデータはコンピュータシステムが出来る
前から存在していて、システムの外で発生して人間が入力するもので、いざと
なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
には可能です。

少なくともそうしたものを暗黙的に想定します。

> 別にCやCOBOLのようなオブジェクト指向言語でないもので開発を行うのであれば、OODBなんてまったく無意味でしょう。

これも不思議です。プログラムの構造そのままに格納したいのであれば、オブ
ジェクト指向云々とは全く関係なくその要望はあるように思います。例えば
ObjectStoreがプログラム実行時の仮想メモリをそのまま保存できるからすご
いんだ、と宣伝していましたが、仮想メモリはオブジェクト指向によってもた
らされたものではないですし。

> 速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
> 市場に出るのが速かったのか、技術が追いついてなかったのか、それは分かりませんけど。

「OODBは速い」というのは昔々のoo1やOO7ベンチマークでjoinとpointer chasingを
比較したところから始まっていると思いますが、そのときの比較はRDBもOODB
も研究用プロトタイプで行っていたように思います。実際の性能なんてモデル
なんかよりも実装テクニックの方がはるかに影響が大きいと思うんですけど。

結果やその伝聞を真に受けて「RDBをOODBに入れ替えれば速度が1000倍になる」
と早合点して、無茶なシステムの企画を立てた人がもしかしたらいたのかも。

#そういえばObjectStoreに不利な結果が出たから弁護士を使って論文から削
#除させたこともあったような。


94 NAME IS NULL


04/07/23 12:55 ID:???

91
> RDBは現実のモデルを正規化という手法によって2次元のテーブルを設計していくわけですよね。

2次元の表ではなくて、正式にはリレーションだし、現実的には単なるレコー
ド設計でしょう。レコードを沢山集めて2次元に表示できるということなら、
オブジェクトを集めたって同じことが言えると思います。

複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
queryが付いたりする。

> システム開発に置いて前提条件がくつがえって、既存テーブルの主キーを変更せないかんような
> 状態になったり、今まで必須だった項目がまったく不要になったり、、
> 結構頻繁にあるんですよねえ。

ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる/なりそ
うなんでしょうか。

> O/Rマッピングツールでしたら、私のお薦めはこれ。
> http://www.ibatis.com/common/sqlmaps.html

O/Rマッピングというよりも、既存のオブジェクト指向モデルがあってそれが
すでに稼動している場合、前提条件が覆ってモデルの変更が発生した場合に、
旧モデルから新モデルへの移行は現在保存されているオブジェクトを含めて自
明な方法になるんだろうか、という疑問です。

MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印
象を持っていますが。

> 仕事上、こりゃ一から作り直した方がいいやってことは頻繁にあります。けど選択肢は2つあります。
> ・一から作り直す。
> ・今のを修正して、無理にでも動かす。(もち問題先送り)
> で、偉いサンも偉くない人も下側が好きな人が多いんですよね。
> まあ、多数決で「こりゃ一から作り直した方がいいや」って思う人が増えなきゃねえ、、、

この場合の一番の判断要因はもちろんコストでしょう。

95 NAME IS NULL
04/07/23 21:28 ID:???

93
> あぁ、この辺の感覚が私とは違いますね。「プログラムの中にあるデータを格
> 納したい」とは考えないです。

 研究者の方ですか?


> だってデータはコンピュータシステムが出来る
> 前から存在していて、システムの外で発生して人間が入力するもので、いざと
> なればシステム無しでも伝票の山と格闘すれば、業務を遂行することが物理的
> には可能です。

 えーっと、無理です。きっぱり無理です。遅くとも10年前ほどから現実的にも論理的にも不可能です。
人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか?
経済はお金ができる前から(物々交換など)存在していますが、いざとなればお金がこの世から無くなっても、、
水道は、電気は、車は、

ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。

やっぱり私とは考え方というか感覚が違いますね。(だから楽しい!)


> > 別にCやCOBOLのようなオブジェクト指向言語でないもので開発を行うのであれば、OODBなんてまったく無意味でしょう。
> これも不思議です。

 不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか?
ディスクと同じだけのメモリが必要なのでしょうか? だったらある意味すごいです。


96 NAME IS NULL
04/07/23 21:43 ID:???

94
> レコードを沢山集めて2次元に表示できるということなら、
> オブジェクトを集めたって同じことが言えると思います。

 そうかもしれません。


> 複雑な構造も表現するから、Oracleにconnect byが付いたり、DB2にrecursive
> queryが付いたりする。

 だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません?
オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。


> ありがちな災難wかもしれませんが、OODBだとその対応が簡単になる/なりそ
> うなんでしょうか。

 んー。正確には、適切に設計されていればコードの変更箇所が必要最小限となり、影響される範囲も限定されるわけです。
DBどうのこうのじゃなくて、システム設計の話になりますね。

で、言語で言えば、BASICに比べればCが、Cに比べればJavaが、「適切に設計」されてさえいれば安全性が増しますね。
JavaだからOODBとなったわけで、BASICやCOBOLならシーケンシャルファイルでしょうか。

話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。(w



> MDA方面でよっぽど素晴らしい成果が出ないと難しいんじゃないかなという印

すいません。MDAって何ですか?


> この場合の一番の判断要因はもちろんコストでしょう。

ビジネスの世界ではコストより時間が優先されがちです。
時間=コストと考えれば、コストですね。


97 NAME IS NULL
04/07/23 23:19 ID:???

>話はそれましたが、OODBだとその対応がって質問ですが、だってRDBのテーブル再設計の手間がまるまるなくなるじゃんって思っちゃうわけで。(w

それは幻想のような。
ただのプログラムだって最初の分析が甘ければデータ構造の
見直しが発生しちゃうわけだし。

逆にDOAなど分析手法が確立しているRDBの方が危険性が
少ないようにも思うんだが。

98 NAME IS NULL
04/07/24 16:35 ID:???

97
よく分かんない。
まあだいたいトレードオフするものだから、どっからみても完璧なんてあり得ないんだけど、
もし仮にそういう完璧な設計&プログラミングができたとしても、それはその時点でのモデルだよね。


99 NAME IS NULL


04/07/25 01:31 ID:???

98
どうせ完璧なんて無いんだから、どうしたら「マシ」なのかを探るべきだと思います。
#週末で酔っぱらってるので本レスはまた来週。


100 NAME IS NULL
04/07/25 10:28 ID:???

99
1)業務を変えない。 無理だな。
2)業務を変えるたびにシステム再構築し直す。 無理だな。
3)業務に変更があった場合、修正箇所を最小限にする。
  なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。


101 NAME IS NULL


04/07/25 10:40 ID:???

100
> 3)業務に変更があった場合、修正箇所を最小限にする。
>   なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。

それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているDBの場合はどんな考察になるんでしょう?というのがここ
で展開してた議論だと思います。



102 NAME IS NULL
04/07/25 21:40 ID:???

101
> 過去のプログラムの実行結
> 果を格納しているDBの場合はどんな考察になるんでしょう?というのがここ
> で展開してた議論だと思います。

 そうだっけ? 別にRDBからOODBに移行する話じゃなかったと思うんですが。


> それはプログラミングの場合は確立されてるけど、

 だから言語に合わせて(オブジェクト指向分析・設計で)オブジェクト指向言語を使って開発された
システムに無理してRDB使うってのは100の(3)に相反しているというのが私の主張です。

#現実的にはRDBしか選択肢がないに等しいんだけどね。

103 NAME IS NULL


04/07/25 23:45 ID:???

102
>  そうだっけ? 別にRDBからOODBに移行する話じゃなかったと思うんですが。

そうですよ。別に移行の話じゃないですが、「OODBってどうなってるの?」と
いうのが話(やそもそものスレ)の発端でしょ?

>  だから言語に合わせて(オブジェクト指向分析・設計で)オブジェクト指向言語を使って開発された
> システムに無理してRDB使うってのは100の(3)に相反しているというのが私の主張です。

それに対して「別にDBは言語の便宜のために生まれたものじゃないし、使う
ものじゃない」というのが私の主張です。

上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。

システム開発ってプログラミング関連だけじゃなくて方式設計とか、ネットワー
ク設計とか、ソフトウェア構成とか、いろんな要素が絡んでると思うんだけど。

その時に「DBMS」と呼ばれる構成要素に対して求められる機能を考えたときに、
RDBやOODBはどんな特徴として位置づけられるんだろう、と考えるのが重要だ
と思います。


104 NAME IS NULL


04/07/26 14:10 ID:???

95
>  研究者の方ですか?
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。

OODB出始めは本当にアカデミック方面しか資料が無かったし。

でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、

>  えーっと、無理です。きっぱり無理です。遅くとも10年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。

もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。

カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。

企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。

データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。

> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか?

少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。

> 経済はお金ができる前から(物々交換など)存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、

水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
#極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。

> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。

実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?

システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
#制御系の話はよく分からないんでパス。

>  不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか?
> ディスクと同じだけのメモリが必要なのでしょうか? だったらある意味すごいです。

パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。

相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。


105 NAME IS NULL


04/07/26 14:24 ID:???

96
>  だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません?

プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。

> オブジェクト指向言語でないものは例えばレコードをそのままの形で格納したものがシーケンシャルファイルであったりしたわけだと思うのです。

オブジェクト指向以外の言語において、プログラミングの便宜のためにレコー
ドの概念が導入されたとは思えません。それは言語の問題の外からの要求に応
えたものだと思います。そしてその関係はオブジェクト指向言語でも変わるべ
きではないと思います。(というか変わる理由が分からない)

> すいません。MDAって何ですか?

Model Driven Architecture(だったかな?)。標準的なオブジェクト指向の道具
立てがそろってきたから、ここらでもう1回CASEの夢を見ようという動きだと、
私は理解をしています。

> ビジネスの世界ではコストより時間が優先されがちです。
> 時間=コストと考えれば、コストですね。

すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
沢山出て来そう)ということでしょうか。
#新規の話じゃないですよね。

まあ実際は資産を除却するよりも、追加で出来るならそっちの方が良いという
判断かもしれませんが。


106 NAME IS NULL
04/07/26 20:16 ID:???

103
>それに対して「別にDBは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。

 DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか?
それとも相互に影響を与えながら進化していっているのでしょうか?


">研究者とくるとは、、、

 それとも学生か学者かと。


>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理

 別に揚げ足じゃないですが、判を押した請求書をつくらないところもありますよ。入金チェックは自動でしているところもあるでしょう。
人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。


>便利な手段があるからといって、目的と混同すべきではないです。

 便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
手段や目的とはその上で語られる別次元のものです。


>パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
>チして、サーバのディスクからページを転送してくるらしいです。

 面白そうですね。OSいらんやんって思いました。
OSいるんですかね? httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。



107 NAME IS NULL
04/07/26 20:31 ID:???

>相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか

  C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。


>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。

 外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。


>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。

 これはOODBの場合って話ですか? なぜでしょう?
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。


>Model Driven Architecture(だったかな?)。

JavaWorldの5月号に特集を見つけました。今度読んでみます。


"> ビジネスの世界ではコストより時間が優先されがちです。
"> 時間=コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。

 いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし5ヶ月かかる。
・今のをむりやりにでも動くように修正すれば1ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、4ヶ月の時間差(=コスト)がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に4ヶ月分だけの価値(=利益)があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。


108 U </b>◆CZtFsGiu0c <b>
04/07/26 21:08 ID:???

なんか盛り上がってますね。現役のObjectStore使いです。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
88
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。

OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。
#ただし私が関わっているシステムはそのどちらでもありません

90
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。

ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
悲惨です。クライアントのキャッシュが肥大してメモリ不足になってしまう
なんてこともあります。

OODBが通常の業務システムに使われないのは、まず技術者が不足している
こと、ベンダのサポートが不安なこと(今はわかりませんが、昔はひどい
もんでした)、それとなにより業務システムにありがちなアドホックなデータ
操作(参照系、更新系含む)が難しいことでしょうか。なにかあるたびに
プログラムを一本作らなければならないのでは、運用が困難です。

ただ、個人的にはOODB(っていうかObjectStore)のキャッシュが使えたらな
、と思うことはよくあります。どんなデータかというと、

・参照は頻繁にされる。また、参照のコストが高い
・更新の頻度は少ないが、更新は即時に反映される必要がある

ようなものです。例えばリソースに対するアクセス制御データとかですね。

109 NAME IS NULL
04/07/27 00:40 ID:f4b3F8Gz

非常に面白いスレですね。OODB未経験ですが割り込ませてください。
(U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。)

今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか?

実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
(最終的にはCORBA/CCMまで絡ませたい)
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること(ユーザインターフェイスを含む)」なのです。
(以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。)

ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
(MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう)。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ(例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール)が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか?
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
(ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします)



110 NAME IS NULL
04/07/27 00:42 ID:f4b3F8Gz

続き。

あと個人的な意見ですが、OODB(やXMLDB)がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
まずは上級エンジニアが触ってみて遊んでみて「いいな、コレ」って思ってもらわなければ、いつまでたっても一部のコアな開発者のマニアックな玩具に留まってしまう気がします。

それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応(←これ重要!2バイト対応されていない製品はユーザに嫌われる)
といったようなものがサクっと出てくるようでないと・・・。
(フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・?)




111 U </b>◆CZtFsGiu0c <b>
04/07/27 12:35 ID:???

109
>(U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。)

お久しぶりです。
#と言ってもどなたかわかりませんが:-)

>今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか?

ObjectStore以外のOODB製品はよく知らないのですが、最近Cacheという
製品が気になっています。これが謳い文句どおりの製品ならかなりのもの
ではないかと思うのですが、ちょっと眉に唾をつけてます。暇があれば、
試用版を使ってみたいと思うのですが。

>あと個人的な意見ですが、OODB(やXMLDB)がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。

XMLDBなら、Apache Xindiceはかなり簡単です。私はダウンロードして5分で
とりあえず使えるようになりました。


112 NAME IS NULL


04/07/27 16:04 ID:???

106
>  DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか?
> それとも相互に影響を与えながら進化していっているのでしょうか?

もちろん相互に影響を与えているでしょう。

>  それとも学生か学者かと。

ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
なんでしょうか?

> 人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
> それ以外の単純作業は遅かれ速かれ自動化されていくでしょう。

「確認」も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。

>  便利な手段はすでにインフラとして水や空気のように無くてはならないものであり、あって当然のものです。
> 手段や目的とはその上で語られる別次元のものです。

アパートを借りる人や都市計画を考える人にとっては水道管はあって当然です。
あって当然ですが、断水してるとか、そもそも水源から繋がってなかったら話になりません。
この例ではITという便利な手段を「構築する人にとって」どう捕らえるべきかという話でしょ?

>  面白そうですね。OSいらんやんって思いました。
> OSいるんですかね? httpサーバ内蔵してそれで設定できりゃあ、それ以外の入出力装置は必要なさそうだし。

OS組み込みのモジュールならば面白いかもしれませんがOSを置き換えたり、単
独で立ち上げて外部に公開するもんじゃないと思います。

NW・CD-ROM・マウス・キーボードドライバも用意して、コンテキストスイッチ
機能も入れてDBマシンとしてハードウェアごと用意するのは有りかもしれませ
ん。(使いにくそうだけど)




113 NAME IS NULL


04/07/27 16:41 ID:???

107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。

まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。

>  外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。

開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?

>  これはOODBの場合って話ですか? なぜでしょう?
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。

いくつか考えられますが。

1:DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。

最初に作った人はハッピーなんでしょうけど。

いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。

2:オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか?

システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。


3:基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。

思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。

> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。

このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。

#実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
#てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。


114 NAME IS NULL


04/07/27 16:54 ID:???

108
> OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。

CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。

> ObjectStoreに関して言えば、速度はキャッシュが有効に使えるかどうか、
> につきると思います。キャッシュが効くシステムなら「速度1000倍!」も
> あながち嘘とは言い切れません。ただしキャッシュがうまく使えないと
> 悲惨です。

買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。

> ・参照は頻繁にされる。また、参照のコストが高い
> ・更新の頻度は少ないが、更新は即時に反映される必要がある
>
> ようなものです。例えばリソースに対するアクセス制御データとかですね。

この利用例のアーキテクチャはどうなっているでしょうか。個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。


115 U </b>◆CZtFsGiu0c <b>
04/07/27 19:23 ID:???

113
>1:DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。

確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。

>2:オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。

これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
高いと思います。

114
>CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。

一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
間で同一データを扱っている際に、更新を即時に反映できることです。
通信系システムで採用されている理由も同じでしょうね。
#もう一つ共通点としては「データの再利用」や「アドホックな操作」が
#不要なことも挙げられます

>買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。

ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
とプログラムが異常終了します:-P

>この利用例のアーキテクチャはどうなっているでしょうか。

まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。

>個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。

すいません、つながりがよくわかりません。




116 NAME IS NULL


04/07/27 19:56 ID:???

115
> できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
> 高いと思います。

個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。
ログをXML形式で溜めていくのはありそうですけど。

#インデキシングやトランザクション・排他制御管理がどうなっているのかはぜ
#んぜん追っかけてません。

> 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
> 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
> 間で同一データを扱っている際に、更新を即時に反映できることです。

部品管理システムと連動したアプリケーション、というイメージでしょうか。

> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。

いいえ、上で書いた知識でほぼすべてです(笑)。

> すいません、つながりがよくわかりません。

アクセスするアプリケーションが固定で、そのアプリケーションを捨て去ると
きにはDBも破棄してしまうとか。「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。
業務系・情報系のようにDBを置いておいてあちこちからアクセスされるのを待っ
ているという形態ではないと。

そして、ObjectStoreの「仮想メモリをそのまま云々」というのはそうした
(制御系?組み込み系?)の方が向いてるんじゃないかと想像しています。だか
ら私はObjectStoreは好きになれそうも無いけど、PSEはなんとなく良い印象を
持っています。

#全部想像ですけど。



117 NAME IS NULL
04/07/28 22:13 ID:???

112

> ベンダからのプレゼンや、本屋に並んでいる入門書に載っている用語しか出し
> てないですよ。プログラミングに注力してる人たちだと、例えば「○○パター
> ン」とか「アジャイル云々」と言葉にする人は学生や学者ばっかりという感じ
> なんでしょうか?

 さあ? 何となく、プログラマではないなと思いまして。私はプログラマですが。
研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。
他意はありません。

#2chでまじめに議論できるとはめずらしいスレですね。パソ通みたいで懐かしいです。


> 「確認」も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
> 能性よりも業務体制の問題でしょう。経理部門内が自動化されても、担当各部
> 署にリストを送付して「確認しといてくれ」、ぐらいのことはやらないと。

業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
下す必要があるときだけ、ユーザに伝えればいいと考えます。


118 NAME IS NULL
04/07/28 22:19 ID:???

113

> まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
> 象は違わないし、保存する必要性も変わらないと思います。

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


"> esql/c でもpro*cでもいいですが、プリプロセッサです。
>
>開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?

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



119 U </b>◆CZtFsGiu0c <b>
04/07/29 12:25 ID:???

116
>個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。

複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
ほうが扱いやすいです。

>部品管理システムと連動したアプリケーション、というイメージでしょうか。

そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
という仕組みに使われているはずです。

"> まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。
>いいえ、上で書いた知識でほぼすべてです(笑)。

各クライアントがメモリ上にキャッシュを持っており、キャッシュ内のオブジェクト
を更新すると、その更新が他のクライアントのキャッシュにも反映される、という
ことでおわかりになるでしょうか。

>「リソースに対するアクセス制御データ」と
いうところからそうしたものを想像しました。

たとえば、NTドメインのユーザ/グループ情報と、ファイルに対するアクセス権
の設定をマッチさせて、現在のセッションのユーザが指定されたファイルに対して
指定されたアクションが実行可能かを判別する、といった感じでイメージして
いただけるでしょうか。


120 U </b>◆CZtFsGiu0c <b>
04/07/29 12:26 ID:???

118
>組込型言語とでもいうんですかね。忘れました。

埋め込みSQL(Embeded SQL)ですね。

121 NAME IS NULL


04/07/29 13:19 ID:???

117
>  さあ? 何となく、プログラマではないなと思いまして。私はプログラマですが。

確かにプログラマではありません。人の作ったソースの一部を性能チューニン
グのために見たりいじったりしたことはありますが。

システム開発の時にはプログラミング以外にもいろんな技術要因が絡んできま
すよ。

> 研究者か学者っぽいなと思ったのは、ちょっと哲学してるからです。

業界に何年かいれば、誰でもある程度のシステム観とかポリシーみたいなもの
は出来てくるんじゃないでしょうか。

> 業務にもよりますが、なんでもかんでもチェックリスト出すより、自動的にエラー回避するなり
> 自動修正するなりしてくれればそれで問題ないと思います。それが無理なときや人間が判断を
> 下す必要があるときだけ、ユーザに伝えればいいと考えます。

この場合例に出していたのは経理の入出金ですからチェックしなきゃいけない
でしょう。月次締めなどを経理の人が必死でやってませんか?そもそもどの請
求書に対応した入金かどうかなんて、十分な情報がある保証は無いですし。

業務上運用手抜きしてノーチェックにしてしまう可能性はありますが。少なく
ともいつでも確認できる状態にしておかないと、システムにバグがあったとき
に対処できないし、会計監査も危ないんじゃないでしょうか。

監視ツールがログを監視して警告を出す、というような場合は通常は無視して
しまって、問題が起こったときに「ここまでは正常だった」ということが分か
れば良いと思います。


122 NAME IS NULL


04/07/29 13:41 ID:???

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

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

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

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

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

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

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

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

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

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

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


123 NAME IS NULL


04/07/29 14:10 ID:???

119
> 複雑な構造のものは、下手にテーブルに分解するよりもXMLでそのままストアした
> ほうが扱いやすいです。

XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、

・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。
・referenceは結局ID属性を使いまくりになる。
・そのときの排他制御がどうなるのかいまひとつ分からない。
・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。

というあたりが不安視するところです。

> そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
> 即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
> 状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
> という仕組みに使われているはずです。

なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。
#competitorはRDBじゃなくてCORBA。

ObjectStore限定の性質なのか、OODBに共通して見られる特徴なのかは分かり
ませんが、確かにそれは便利そうです。RDBで無理にやろうとしたら定期的に
リクエストを投げてpollingしなきゃいけないところです。

やはりOODBは組み込み向け(機器組み込みじゃなくてアプリケーション組み込
み)に向いている感じがします。

だとするとベンダの営業文句は根本的にはずしてる気がする。今はどうか知り
ませんが、かつては「次世代の企業内基幹システムはオブジェクト指向開発が
広まってOODBだ!」っていう風じゃなかったでしたっけ?


124 NAME IS NULL


04/07/29 14:35 ID:???

115
> ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
> とプログラムが異常終了します:-P

これ、スルーしようか迷ったけどどうしても気になって。

さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。

たぶんPage fault利用のアーキテクチャに起因するもので、10年以上バグでは
無く仕様と主張しているんじゃないでしょうか。(推測)

===以下、推測が合っているとして===

普通製品でこんなことが起こったら致命的な障害としてベンダが認識して、ど
こかのバージョンアップ時に修正されるはずだと思います。

修正不可能だったら販売中止にすべきだし、R&D時に「原理的に修正不可能」
と判明したのだったら製品販売ビジネスをあきらめるはずです。その代わりに
開発請負ビジネスに変更して自社内利用に留めておくとか。

変なドライバを入れたらOSが落ちまくるので苦情の電話を入れたら「仕様です。
マウスはあまり激しく動かさないでください」と言われ、しかもそのままの品
質で10年以上も販売し続けているようなものだと思います。

「作ってたら何か出来ちゃった。出来ちゃったから売っちゃおう。動かしてど
うなるかは知らないけど。」と考え続けているように見えます。

技術的にも営業的にも、モラルに問題があるとしか思えません。


125 U </b>◆CZtFsGiu0c <b>
04/07/29 17:32 ID:???

124
>さすがにクラッシュするのはサーバではなくクライアントだと思いますが、こ
れって製品として外に向かって販売できる状態じゃないとしか思えないです。

クライアントの話です。ただし、誤解のないように言っておくとメモリ
不足を捕捉して安全に終了するようにはできると思います。ただし、
どちらにしてもアプリケーションの続行は不可能なので、問題は問題
ですね。

…とここまで書いて、本当に合っているのか不安になったのですが、
ここでフォローしてもらうのは無理かな。

ああ、そういえばObjectStore付属のツールであるInspectorは、かなり
あっさり落ちます:-P

126 NAME IS NULL


04/07/29 20:06 ID:???

125
> クライアントの話です。ただし、誤解のないように言っておくとメモリ
> 不足を捕捉して安全に終了するようにはできると思います。

SIGSEGVをキャッチしたり、定期的にsbrkで調べたりとかでしょうか。自分が
作ろうとした機能のためにやるんならともかく、買ってきた製品のためにやる
必要があるんだったら相当使いづらいですね。

ドライバを作る繊細さで業務アプリを構築するような。明らかに一般公開する
レイヤを間違えている気がする。

Java版もあったと思うんですが、同じことは出来るのかな。
どっちにしろ業務中断になるけど。

127 NAME IS NULL
04/07/29 20:37 ID:???

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

 では何だったらいいのでしょうか?


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

 聞かれたから答えたのに。シクシク


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

(1について)
別にRDBでもOODBでも同じ問題だと思います。

(2について)
確かにそうですね。

(3について)
そうは思わないです。ただのいちゃもんに聞こえます。


>・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
>なんて考えないでしょ?

言語依存のOODBじゃなくてWebサービスならOKってことでしょうか?




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


128 NAME IS NULL
04/07/29 20:38 ID:???

123
>だとするとベンダの営業文句は根本的にはずしてる気がする。

ベンダの営業文句が根本的にはずして無かった事ありましたっけ?

129 NAME IS NULL


04/07/29 22:55 ID:???

127
>  では何だったらいいのでしょうか?

それで今のところラッパーが世に出てきてるということでしょう。
将来もっと便利な解決策が出るかもしれませんが。

確認ですが、ここで展開されている議論はOODBを使うとか、言語オブジェクト
をそのままDBに入れる手法についてどう思うか、ということですよね。

「ラッパーで良い」、ということなら「そうですね」という答えになります。

少なくともObjectStoreの提供するアーキテクチャとか90で書かれた「イン
スタンスのまんま(オブジェクトのまんま)格納や抽出なんかができれば」と
いう状況は、理想とはほど遠いと主張しています。

>  聞かれたから答えたのに。シクシク

104では「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると
認識していたんだろう?」という質問をしています。

私の考えでは、「開発」の手法や便宜よりも「実行」の方が重要性が高いです。
#もしかして「実行」と聞くと「コンパイル」をイメージしますか?

> (1について)
> 別にRDBでもOODBでも同じ問題だと思います。

最初に出来たオブジェクト指向設計・実装の成果が、たとえば5年間(償却す
る間)ぐらいはそのDBにアクセスするアプリケーション開発に強制的に利用で
きると考えて良いでしょうか?(開発環境はずっと同じと仮定)

分析あたりまではともかく、設計や実装は難しいんじゃないかという印象を持っ
ています。

私はアプリ実装の都合と関係のない設計の方が長持ちする可能性が高いと思い
ます。もちろんRDBにしたところで、いつの間にかフラグ情報が山のように入っ
てきて身動きがとれなくなってしまうことは良くあります。
変な情報が入りすぎてしまうと、きれいに作り直そうとも移行できなくなって
しまうでしょう。

> (3について)
> そうは思わないです。ただのいちゃもんに聞こえます。

これは私のプログラマ観(というか、オブジェクト指向屋観)なので、確かに
根拠や論理性がなかったです。_o_

> >・じゃあHTMLは止めてJavaオブジェクトを直接やり取りするようにしよう。
> >なんて考えないでしょ?
>
> 言語依存のOODBじゃなくてWebサービスならOKってことでしょうか?

いいえ、HTMLとHTTPという言語とは関係のない便利なものがあるおかげで、い
ろんなブラウザから同じサーバにアクセスして同じ情報を閲覧できるようになっ
ている、ということです。

まぁ、表示が大幅に崩れたり、アプレットやスクリプトやフラッシュがどんど
ん入ってきて混乱した状況ですけど。


130 NAME IS NULL


04/07/29 23:21 ID:???

128
> ベンダの営業文句が根本的にはずして無かった事ありましたっけ?

「誇大妄想か?」と思うような表現はデフォルトですが、適用ジャンル・レイ
ヤを大幅にはずすことはそんなにないでしょう。

PhotoShopでVBスクリプトが使えるみたいですが、だからといってアドビが
「基幹システム開発に革命をもたらす!!」とか言ってSI市場に売り込み攻勢
をかけたら「アホか」と思うでしょ?
#ODBCが使えるのかどうかは知らない。


131 U </b>◆CZtFsGiu0c <b>
04/07/31 13:15 ID:???

123
>XMLはツリー構造になってその中で完結しているので、DB全体で1文書扱いなの
か1データ1文書扱いなのかがいまいち理解できてませんが、

DB全体で一つの文書、というのはまずないでしょうが、どの単位で一文書とするかは
設計次第ですね。

>・ツリー構造限定なのでreferenceが複雑なのではなく、compoundが複雑な場
合にのみ効力を発揮する。

現状ではそのとおりです。

>・referenceは結局ID属性を使いまくりになる。

参照に関しては、XPointerやXLinkなどの技術がXML-DBに取り入れられるのを待つ必要
がありますね。

>・そのときの排他制御がどうなるのかいまひとつ分からない。

これは実装依存です。

>・XQLなどによって検索する場合に、どの程度のインデックス機構が用意され
ているか分からない。

XQL? XQueryのことですか? インデックスも実装依存ですね。

>なるほど、なんとなく分かってきました。(下の方の解説も合わせて)私なりに
理解すると、ある特定のアプリケーションが主役であって、何かを保存すると
いうよりも同種アプリケーション間通信のためにOODBの機構を利用するという
感じでしょうか。

とはいっても、オブジェクトの変更に対する通知のみですので、RPC系技術の代替に
なるわけではありません。が、状態の変更をリアルタイムに把握する必要があるシステム
であれば、有効でしょう。


132 NAME IS NULL
04/08/07 14:38 ID:???

Javaは言語でもあるが、Javaはプラットフォームでもある。
別にパソコンに限った話でもない。

将来、Javaに取って代わる言語が現れたとしたら、既存資産であるデータ(DB)
を使えるようなマッピングツールが出るであろう。でなければJavaに取って代わる
可能性はない。

それより先にそのDBMS製品が別のDBMS製品に取って代わられる可能性もある。
そのときに今までのデータの移し替えが容易にできなければならない。

では違うジャンルへのDBへの移行はどうであろうか。(RDBからOODB もしくは
OODBから次の世代へ)
移行できるかもしれない。コストにより移行が現実的でないかもしれない。

RDBではいろんな言語から使える。
なぜOODBはJavaだけなのか? Java以外にオブジェクト指向言語が普及して
いないだけではないのか?

視点を変えてみる。
JavaではいろんなジャンルのDBMSが扱える。
実はそれだけの話なのかもしれない。


133 NAME IS NULL
04/08/07 14:47 ID:???

130
ベンダーの宣伝文句はベンダーの主張であり、アピールポイントです。
ですがそれが私たちユーザから見て、ベンダーの理想が実現するとは限らない。
なぜならそれはベンダーの理想だから。

Adobeの製品を使えば夢のようなデジタルでペーパーレスな世界が広がります。
マイクロソフトの製品を使えば、生産性が向上します。
別にどこのベンダーの製品でもいいですけど。

ほんとにそれが100%実現した事がありますか?

身近なところで言えば、マイクロソフトの新OSが発表されるたびに、前回のOSのときも、
そのまえのOSの時も、同じ宣伝文句だったよなあとデジャブーを体感させられます。

134 NAME IS NULL


04/08/09 11:56 ID:???

133
いや、「100%で非の打ち所がないかどうか」ということではなくて、理想と主
張と製品機能はそんなにぶれてないでしょ?と書いたつもりです。

「100%実現してないからタコだ」なんて文句言っても、あんまり意味無いと思
います。悪口言ってストレス解消するならいいけど。

理想に向かって少しでもマシな状況になれば良しとすればいいんじゃないかな。

上のObjectStoreの例で言えば

・クライアントサーバ構成をとっている。
・宣伝文句では基幹システム向けとかポストRDBというふれこみだった。(今も?)
・にもかかわらず言語依存度が高い。→拡張性に問題があると考えられる(CODASYL時代へ逆戻り)
・アーキテクチャに起因する問題がありそう(クライアントクラッシュ)

という点から、ベンダの理想と主張と製品機能がそもそも噛み合っていないと
書いたつもりです。


135 U </b>◆CZtFsGiu0c <b>
04/08/10 00:42 ID:???

132
JavaしかサポートしていないOODBってなんですか?
ほとんどの商用OODBはJavaの普及以前から存在するのですが。

問題なのは、例えばJavaプログラムからストアしたオブジェクトをC++プログラムから
扱えない、とかそういうことなのですが。

134
>・クライアントサーバ構成をとっている。

これ自体には問題はないと思うのですが、何か問題ありますか?

136 NAME IS NULL


04/08/10 01:34 ID:???

135
> >・クライアントサーバ構成をとっている。
>
> これ自体には問題はないと思うのですが、何か問題ありますか?

書き方がわかりにくかったですが、箇条書きの1個目と2個目を受けて3個目
を書いています。

ObjectStore(あるいはOODB一般?)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。

しかし「クライアントサーバアーキテクチャ」といった場合には、アプリケー
ションが特定されないか、少なくとも数種類のアプリケーションは存在してい
るシステム構成を暗黙の前提としていたはずです。(Xサーバとかは又違う気
もしますが、DBサーバを使った業務系システムということで)

ずっと名無しで書いているので、私のレスがどれか分かりづらくなってきたの
で、リファレンスをここで作っておくと、
40,42,58,60,63,66-68,77,79,84,86,88
89,93,94,99,101,103-105,112-114
116,121-124,126,129,130,133
です。
(結構多いなw)

何人で議論してるのかも分からなくなってきたw


137 U </b>◆CZtFsGiu0c <b>
04/08/10 11:56 ID:???

136
>ObjectStore(あるいはOODB一般?)は特定のクライアントアプリケーションし
か動かないことを暗黙の前提にしたアーキテクチャだと感じています。

もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
テクチャを想定していませんか? だとすると、それは勘違いですよ。それに
OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
アプリケーションでしか使えないなんてことはありません。
#だから組み込み云々って話になっていたのか

138 メソドロジスト
04/08/10 12:25 ID:???

ODB(もどき)を自作しているか自作してみたい人いませんか?

139 NAME IS NULL


04/08/10 14:04 ID:???

137
> もしかして「クライアント/サーバ」って言葉はよくある2層構造のアーキ
> テクチャを想定していませんか? だとすると、それは勘違いですよ。

いわゆるサーバが起動していて、クライアントも実行されて、クライアントか
らサーバへリクエストが飛んで、その結果がクライアントへ帰ってくる、とい
うようなものを想定してました。Page faultでも似たようなものだと思ってい
ます。

「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。

「クライアント/サーバ」に厳密な定義があるわけじゃない、別物だとしたら
SI市場に向けて「クライアント/サーバ」というメッセージを発信することは
やっぱり変だと思います。

#話がうまく噛み合ってるかな?

> それに
> OODBを使ったからといって、(言語は固定されるかもしれませんが)特定の
> アプリケーションでしか使えないなんてことはありません。
> #だから組み込み云々って話になっていたのか

うーん特定のアプリというと御幣があったかもしれないけど、「特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。

で、そこから上の方で書いたような「設計の成果がどの程度の汎用性を持ちう
るのか」という疑問に繋がります。

この辺の感覚がどのぐらいなのか分からないのですが、安心して出せるガイド
ラインとか、「どんなときにどんな風に使えばいいの?」という疑問に対しては
「特定のアプリ専用」とか「組み込み」という感じにならざるを得ないのかな、
という予想です。


140 U </b>◆CZtFsGiu0c <b>
04/08/10 14:30 ID:???

139
>「クライアント/サーバ」という用語はそうしたものだというコンセンサスが
あると思うのですが、ObjectStoreはそれとはまた別ということでしょうか。

そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。

>うーん特定のアプリというと御幣があったかもしれないけど、「特定の設計」
というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
意図です。

だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。

141 NAME IS NULL


04/08/10 15:43 ID:???

140
> そういう理解なら間違いないと思うのですが、だとすればObjectStoreに
> 限らず、RDBMSでもなんでもそういう仕組みだと思うのですが。

その通りです。で、それを受けて134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。

> >うーん特定のアプリというと御幣があったかもしれないけど、「特定の設計」
> というニュアンスで、しかもそれは特定のアプリに依存しがちだろう、という
> 意図です。
>
> だとすると、やっぱりRDBMSなんかでも同じことになると思うのですが。

RDBMSでもそうした問題が皆無じゃないでしょうが、はるかにマシだと思います。
0 や100じゃないからみんな同じと考えるわけにもいかないでしょ?

○特定のアプリを想定せずに設計する(本当に何も想定しないのは不可能です
が、指向性としてベースの設計は)。
OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?

その結果、例えばクラス構成をガラッと変える可能性よりも、正規化したテー
ブル構成をガラッと変える確率のほうが低いと思います。(←根拠となるデータは有りません。)

あるいは、クラスやその中の属性の永続性を意識しながら設計するノウハウが
一般的に浸透している状況なのでしょうか。

○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)
RDB系では機構としては、追加した項目を使わないアプリはそのままでOKです。
これはOODBでは何らかのケアがあるんでしょうか?(Objectivityには何かあっ
たようなおぼろげな記憶があるけど勘違いかも。)

○更に、これは最近考えているんですが、RDB系ではクライアントがある情報
エントリを指定するためにコード(ID)やSQL文といった文字列を使うためにク
ライアント-サーバ間の結合度がlooseになっていますが、OODBでは変数名・
配列名・添字などがそれに相当しています。

そのためソース全体にわたってハードコーディングされた状態になっているた
め、クライアント-サーバ間の結合度がtightになってしまい、RDBに比べて柔
軟性に欠けて使いづらくなっているのではないでしょうか。

XMLを使えばもっとlooseになって接続の柔軟性が増すでしょうね。(今のとこ
ろクライアント-サーバ間よりもシステム間接続で人気みたいですが)

#最後の主張は最近思いついたので、多分穴有りまくり。


142 U </b>◆CZtFsGiu0c <b>
04/08/10 16:14 ID:???

140
>その通りです。で、それを受けて134の箇条書きの3つ目で時代を逆行するよ
うなアーキテクチャを取ることに対して疑問を投げているのです。

「時代に逆行」というか、キャッシュアーキテクチャを取っているための
トレードオフと考えたほうがいいでしょう。キャッシュにロードされる
オブジェクトのトータルサイズが、キャッシュサイズに収まればいいわけ
なので、システム設計時にサイジングをきっちりおこなっていれば問題
ないわけです。
#ま、理想論なのは承知しています

>OODBの場合、アプリケーションに起因する構成や属性情報などが余分に入り込
みやすいんじゃないでしょうか?

OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
変わらないはずです。逆に変わるとすると設計に問題があるでしょう。

>○スキーマの変更(項目の追加等)に対応しやすい(これも実際にやるには性能の問題が絡んできちゃいますが)

確かにObjectStoreでは大変でした。現バージョンでは改善されているかも
しれませんけどね。XPで有名なKent Beckは「日々のスキーマ更新」を
プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
はスキーマ更新が簡単なのですかね?

143 NAME IS NULL


04/08/10 17:04 ID:???

142
> 「時代に逆行」というか、キャッシュアーキテクチャを取っているための
> トレードオフと考えたほうがいいでしょう。

「キャッシュアーキテクチャ」を主眼にとっているのなら、やはり「クライア
ント-サーバ」とはレイヤが異なっていると感じます。
どちらかというと「共有メモリ」とか「ソケット」に近いんじゃないでしょうか。

「システムをクライアントサーバ方式で構築する」とは言っても「システムを
共有メモリ方式で構築する」というのは違和感を覚えます。

「共有メモリ」を無理やりシステム方式のレイヤへ持ってくるようなおかしさ
を上のキャッシュアーキテクチャでは感じます。

他のOODBではサーバへOIDをリクエストして、目的のオブジェクトをクライア
ントが取得すると思うので、こうしたことは当てはまらないと思いますが。

> OODBだろうがRDBだろうがXMLDBだろうが永続化すべき情報は基本的に
> 変わらないはずです。逆に変わるとすると設計に問題があるでしょう。

その通り、変わりません。設計に問題が出やすいかどうかです。以下は私の感
じていることなのでプログラミング畑の人のほうが距離感がわくでしょうから
コメントが欲しいところ。

RDB系の場合、DB設計担当者が永続化に特化して作業します。また、機構上ア
プリの構造が入り込むことはありえません。
(だからアプリ設計者からSQLへの不満が出てくるわけで)

OODBの場合はどうなるんでしょうか?

アプリ設計者がDB設計者も兼ねるのなら、OO設計で永続性に注意してクラスを
区分するような設計が望めるのでしょうか。(これは上の方に書いたレコード
設計とジャンプテーブル設計に関する文化の懸念)
#ObjectStoreの場合、どういう永続化設計をしなきゃいけないのかは知らないです。

永続化クラスを専門に設計する担当者がいるのなら、そのクラスを使うアプリ
設計者は設計の自由度が無いと感じたり、「作ったクラスがそのまま永続化」
というOODBが目指した利点を享受できないことにならないでしょうか。

その永続化クラス設計者はクライアントのアプリケーション特性、マシン環境
と共にサーバのマシン環境やネットワークにまで考慮が必要となり、求められ
る技術スキルがRDBと比べて驚異的に高くなってしまい、敷居が高くならない
でしょうか。

> XPで有名なKent Beckは「日々のスキーマ更新」を
> プラクティスとして掲げていたと思いますが、Kentが使っていたGemStone
> はスキーマ更新が簡単なのですかね?

GemStoneはSmalltalkベースですからC++ベースのものよりはやりやすいかもし
れませんね。(←単なる印象論)

XP(というかオブジェクト指向も含むプログラミング関連トピック全般)は「す
でに保存したデータ」に関しては何も考慮していないんじゃないでしょうか。
で、現実はそうもいかないからDBにアクセスしなきゃいけなくなって「面倒く
さいな」と不満が出る。


144 NAME IS NULL
04/08/15 01:31 ID:eZJV+s8t

RDB、OODBのどちらが100年後に残っているか
と聞かれたら
OODBに賭けるな。。

145 NAME IS NULL


04/08/15 01:37 ID:???

144
そうかもしれないけど、理由や考え方の経緯を書いてくれなきゃ議論のしよう
がないじゃん。



146 NAME IS NULL
04/08/15 01:42 ID:eZJV+s8t

他の言語からアクセスできないのは
ObjectStoreだけじゃないかな。。
仮想メモリーを使って、そのままオブジェクトをPersistentにするって
Pointer-swizzlingだったけ?
ObjectOtoreが特許持ってるんだよね。



147 NAME IS NULL
04/08/15 02:49 ID:???

146
pointer swizzling という言葉を知らなかったのでググってみた。
永続ポインタを管理する手法のひとつで、類語として
hardware swizzling というのがあるみたいだね。

ええー、でもさ、「ページイン&ページアウトを契機に
他のホストと共有しているメモリオブジェクトの整合性を図る」ってのは、
いろんな分散共有メモリ(Distributed Shared Memory)の実装で
利用されてる方法と認識してる。
複数ホストでポインタを含むデータを効率よく共有しようとしたら
必然的にそうなるのでは。
特許になってるとしたら問題かも。ほんとに特許になってるの?

148 NAME IS NULL
04/08/15 03:08 ID:???

144
RDBの考え方(表があればいろんなデータを貯蔵できる)は
数学の理論みたいなもんだから100年後も残ってると思う。
そのかわり問い合わせ言語はもっといいのが出てると思う。
SQLって確かIBMでしょ?昔はクエイルとかシークエルとか
いろいろあったらしいし。

オブジェクトDBの考え方は、「オブジェクトを払い出す」
という意味で分散オブジェクトの仕組みと統合されていくのでは。
そんでそれは分散共有メモリ(つまりホスト間での共有メモリ)とも
非常に近いと思うよのさ。

149 NAME IS NULL


04/08/23 17:12 ID:???

147
pointer swizzlingはOODB界隈では、メモリ上でポインタを辿る操作をディス
ク上での同等の操作へ置き換える、という文脈で使われていたと思います。だ
からObject Serverでも良いし、極端には裏でSQLが発行されていても良いんじゃ
ないかな。

「共有メモリ」の使い方としては、そこへread/writeするためのフォーマット
をアプリとは別に設計すると思っていたんだけど、分散共有メモリだとまた違
うんでしょうか。
多分「共有メモリを分散する」時にPage Faultを利用するんじゃないかな。(詳
しく知らないけど)

アプリケーションのPage Faultを契機に動作するのは、より正確には「共有ス
ワップ領域」と考えた方が良いんじゃないでしょうか。そんな低レベルの機構
を表にむき出しにしてどうやって活用するのかいまいち分からないし、
ObjectStoreから何か提案されていた記憶もない。

今にして思えば「クライアント・サーバ」と言うよりも「P2P」と呼んだ方が近かっ
たのかも。(それでもP2Pでシステムを構築するイメージがつかめないけど)

特許に関しては、10年ほど前のパンフレットに「特許出願中」と書いてあるのを
見ただけで、実際に成立したかどうかは知らないです。


150 NAME IS NULL


04/08/23 17:20 ID:???

148
SEQUELが今のSQLらしいです。
http://www-6.ibm.com/jp/software/data/developer/column/iroha/23.html

DBMSとして成立するには検索(インデックス)とトランザクション管理・排他制
御と運用支援が必須だと思うんですが、分散オブジェクト界隈ではそうした方
面のことは考えられているんでしょうか。

逆に言えばその3つさえあれば、アクセスするためのインタフェースがSQLでも
オブジェクトでもXMLでも後は好みの問題に過ぎないと思う。


151 NAME IS NULL


04/08/24 22:59 ID:???

OODB と RDB ではデータ設計自体が異なる。RDB では親が複数の子を持つことができず、
それぞれの子が親へのポインタを持たざるを得ない。たとえば、伝票ヘッダと
伝票明細が 1:N の関係であるとき、伝票ヘッダには、従属する伝票明細へのポインタを
持たせることができず、伝票明細に親である伝票ヘッダの主キー(伝票番号)を持たせる、
という構造になる。そして、伝票ヘッダ(伝票番号=123)の明細を取得しようと思ったときに、
伝票番号=123 を持つ伝票明細を検索することで、親から子を辿ったのと同じ結果を得る。
これは、データを横断的に検索できるという RDB-SQL の特性を利用してはいるが、
本来の横断的なデータベース検索とは本質的に異なる。
親が子の情報を持てないために、検索機能を利用しているだけで、
2004/08/01~2004/08/31 の伝票明細を検索するなどの横断的検索とは違うのである。

これが、オブジェクト指向になると、もっと直感的に設計ができる。
つまり、親に子の情報を持たせることができる。コレクションなり配列なりを
使用することによって。

オブジェクト指向(言語)では、現実の事象をオブジェクトとしてモデリングすることを
身上としている。これは非常に直感的で分かりやすい構造を維持できるからだ。
対して、RDB では利用方法を想定して、非直感的な設計を余儀なくされることがある。
上記の子に親のポインタを持たせるというのは、そうしないと辿れなくなってしまうから、
そうしているのであって、現実の事象を直接的にモデル化しているとは言いがたい。

152 U </b>◆CZtFsGiu0c <b>
04/08/24 23:51 ID:???

150
トランザクションをサポートしていないデータベースなんて使えないですよ:-)
インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
と思います。また、排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
最悪デッドロックの嵐になります。

153 NAME IS NULL
04/08/25 00:40 ID:???

149
「共有スワップ領域」はお見事。頂いとく(笑

150
サンQueue。

151の言うことは確かにうなずける。勢い込んでうんうんとやってしまった。
ところが152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな?ということ。

おいらは階層型DBもネットワーク型DBも触ったことないんだが、
当時遅いと言われたらしいRDBがなぜこれだけ発展して、
前記2つがなぜ廃れたか、誰か知らないかな。

手元のモデリング本も参照してちょっと想像してみたのだが、

階層型:無理にでも木構造にしないとだめ。表現力乏しい。
→XMLDBもそうじゃないか?

ネットワーク型:表現力ありすぎ、複雑になってメンテ困難。
well formedな形についての理論が未完成。
→オブジェクトDBもそうじゃないか?

うーむ、もしかしたらリレーショナルの良さは程ほど具合?
直接ポイントできるのは親方向だけで、
子方向には検索という形でしかポイントできない、ということに
結構意味があるのかも知れないなぁ。

154 NAME IS NULL
04/08/25 00:52 ID:26RWSsaC

ところで 150 のページは、内容に対して
著者イラストが若すぎる気がしないか?age

155 NAME IS NULL


04/08/25 15:09 ID:???

#あまり過度にRDBの肩を持つのも嫌だけど。
151
設計というよりも実装の話ですよね?

オブジェクト指向でも親が子の情報を持つわけではなくて、子へのポインタを
持つだけなんじゃないでしょうか。設計において親子関係であることを定義す
ることって出来ましたっけ?(継承時にサブクラスであると宣言するように。)
設計者と利用者の間で合意を取っているだけだと思います。

RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
「left outer join」に相当するわけだし。

OODBだと単純に持たせただけだと、子から親へ辿るのがめんどくさくなっちゃうでしょ?
特定の明細件名をもっている伝票番号一覧を出すとか。
#双方向リンク用のライブラリ等がどのぐらい普及しているものなのかはよく
知りません。

オブジェクト指向でも「期間を限定した伝票明細の検索」は、「検索」機能を
利用するでしょう? キーを指定してサーバへリクエストする代わりに、属性
名や配列の添え字がソースコード中にハードコーディングされているし。

#私はRDBのjoinとOODBのpointer traverseは設計上の意味合いはほぼ同じと
#考えているけど、ここは合意が取れるのかな。

RDBで明らかに足りない、あるいは普及していないのは、型チェック機能など
でしょうね。
IDの更新に対する保護機能も無いし。


156 NAME IS NULL


04/08/25 15:19 ID:???

152
> トランザクションをサポートしていないデータベースなんて使えないですよ:-)
だからインタフェースよりもそっちの方が重要だし、コンパイラに渡す文字列
を書きやすくするためにそっちへしわ寄せが行っていないか、十分検討したい
です。

> インデックスに関しては実装依存だと思いますが、通常コレクションに対して設定できる
> と思います。
ObjectStoreの「コレクション」は普通の意味とニュアンスが違っていたよう
な。Collection型とかとは違うんですよね?

> 排他制御に関しては、ObjectStoreの場合はクラスタ(データの管理
> 単位)単位でロックがかけられます。そのため、どのオブジェクトを同じクラスタに配置
> するかが、設計のポイントになります。なにも考えずに配置すると、ロック待ちが多発し、
> 最悪デッドロックの嵐になります。

#クラスタ単位がどのようなものか分からないので外しているかもしれませんが。

「仮想ページがそのまま」というのから想像すると、コンパイラをhackしてヒー
プ領域の使い方を指示できる、という理解で良いでしょうか。

そこまでする必要があるなら「プログラム実行イメージをそのまま格納」と言
うだけのためには、あまりにも汚くて他の部分への負担が大きいように思います。

Page Faultを契機にしたPage Serverにこだわるよりも、pointer traversalを
契機にしたObject Serverの方がまだ使いやすそうな印象を受けます。


157 NAME IS NULL


04/08/25 15:32 ID:???

153
> ところが152を見て思ったのは、双方向にリンクできると
> 設計が難しく、デッドロックが発生しやすくなるのかな?ということ。

いや、それよりもPage Serverであるがゆえにロックがページ単位となり、コ
ンパイラが仮想ページの中にどのようにオブジェクトを配置するかを理解する
必要がある、ということではないでしょうか。

> おいらは階層型DBもネットワーク型DBも触ったことないんだが、
> 当時遅いと言われたらしいRDBがなぜこれだけ発展して、
> 前記2つがなぜ廃れたか、誰か知らないかな。

はるか上のほうでも書きましたが、UNIX・クライアントサーバブームが訪れた
ときに、そのプラットフォーム上でCSモデルを構築できるのがRDBしか無かっ
たからではないでしょうか。で、Oracleなんかはその流れを逃さずにホスト版
のOracleをUNIXへ移植して売り込み攻勢をかけたと。

だからOracleのコマンドラインツールはUNIXっぽくもWindowsっぽくも無くて、
なんか変な感じでしょ?(もう何年も触ってないけど)

他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。


158 U </b>◆CZtFsGiu0c <b>
04/08/25 17:00 ID:???

153
ところが152を見て思ったのは、双方向にリンクできると
設計が難しく、デッドロックが発生しやすくなるのかな?ということ。

ページロックしかサポートしていないRDBMSで、一つのページに複数のテーブルの
レコードがランダムに存在している状態を想像してみてください:-)

155
同意します。オブジェクトモデルをデータモデルに落とすのは、それほど難しく
ありません。もちろん再帰的な構造を持つものなど、悩ましいものはありますが。
RDBがいいのは、テーブル間の物理的な関係が疎なために、アドホックな参照や
メンテナンスがやりやすいことですね。

157
汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
ですが。

>他の通信ミドルウェア(TPモニタとかメッセージキューイングとかDCEとか)は
もっと後からでてきたような覚えがあります。

C/S全盛の時代より前にありましたよ。


159 NAME IS NULL


04/08/25 17:50 ID:???

158
> 157
> 汎用機上で動くOracleなんてありましたっけ? Oracleといえば最初はVMS、次に
> Unix系というイメージがあるのですが。というか、RDBよりNDBなどの方が古いの
> ですが。

探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。
http://infoboerse.doag.de/mirror/frank/faqora.htm#HIST

> C/S全盛の時代より前にありましたよ。

でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな?

トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。


160 U </b>◆CZtFsGiu0c <b>
04/08/25 20:13 ID:???

159
>探してみたらPDP-11、VAX/VMS、メインフレームの順番だったようです。

本当だ。メインフレームでOracle使ってるって聞いたことないんですが、
やっぱりIBMプラットフォームですかね。
#それにしてもラリーエリソンが技術者だということを知ってる人はどの
#くらいいるのかな?

>でも、UNIX+C/Sの世界に乗り込んできたのはOracleより何年か後だったような。
日本ではそれより前だとASCII+InformixとかUNISYSががんばってたかな?

ああ、Unix限定ですか。それでもTUXEDOとかその頃からあったと思いますが。
MQもあったし、DCE(ってRPCのこと?)もありましたよね。

>トレンドにうまく乗って「クライアントサーバ=とりあえずRDB買っとけ」とい
うセオリーを作り上げたのは見事だと思います。

VB+ODBCでRDBをサーバにしたGUIアプリケーションが容易に開発できるよう
になったのが大きいですね。で、InformixやSybaseはそれに乗り遅れた、と。

161 NAME IS NULL


04/08/25 21:59 ID:???

> 設計というよりも実装の話ですよね?

実装(制限)に合わせた設計を要求されるということある。
これは、実際のデータモデリングとは異なるスキーマ定義を
しなければいけなくなることがある、ということを意味する。

> RDBの場合は親と子の間に双方向リンクが張られているのと同義になると思い
> ます。オブジェクト指向で言う「ポインタを辿る」という操作は、RDBでは
> 「left outer join」に相当するわけだし。

left outer join を使うこと自体がトリックなのである。
left outer join はポインタを辿る操作であるが、A left outer join B とは
"A から B を辿る" ことを意味する。151 で例示した問題では、
"伝票明細 left outer join 伝票ヘッダ" としか書くことができない。
これは、子から親を辿っていることに他ならない。

ここで、ひとつ考えてみて欲しい。その元となる子(伝票明細)の集合は
どのようにして集めるのだろうか? 伝票番号=123 を取り出したいとき、
伝票番号=123 を持つ伝票明細を取り出し、外結合によって伝票ヘッダを
辿ることになる。これは明らかに問題が前後している。伝票ヘッダを辿る前に、
伝票ヘッダの主要素である伝票番号を伝票明細は利用しなければならないのだから。

RDB の設計に慣れた人間ほど、この問題を意識することができない。
得たい結果から、無意識のうちに RDB式のスキーマ設計を行えるようように
訓練されてしまっているからだ。

この伝票問題の設計において、ルーキーが次のような愚かな設計をすることがある。
伝票 1枚あたりの明細数が最大10明細であると決めうち、伝票ヘッダに
伝票明細1行目, 伝票明細2行目, ・・・, 伝票明細10行目 と子へのポインタを
持たせてしまうのだ。これは RDB の設計としては明らかに誤りである。
正規化されていないために、商品A を購入している伝票を検索することが
できなくなってしまうのだから。

しかし、この発想を頭ごなしに否定してはいけない。この発想こそ直接的モデル化なのである。
発想自体は非常に分かりやすく直感的なものである。ただ、RDB においてはスキーマで
表現できないために、「誤り」として否定せざるを得ないだけのことである。このルーキーの
設計を馬鹿にする前に、この発想を直接的にモデル化できない RDB の制限についても
考えてみてもらいたい。RDB がモデル化において完全ではないことが次第に見えてくる。

162 NAME IS NULL


04/08/25 22:01 ID:???

まだ RDB の問題を理解できていないだろうと思う。
もうひとつ例題を示そう。

私、山田太郎には複数の子供がいる。さて、山田太郎の子供を探してきて欲しい。
この世界の住人には同名の人は存在しない。RDB に慣れ親しんだ人達は、迷わず、

select 名前 from 住人 where 父親の名前 = '山田太郎' と書くだろう。

間違ってない。結果は正しい。しかし、あなたは、この正しい結果を得るために
信じられないほどの労力を使ったのだ。信じられない? 簡単な作業だったって?

そんなことはない。自分自身が DBMS になったつもりで上記のクエリを噛み砕いて
実行してみて欲しい。あなたは、世界中の住人を訪ねて周り、「あなたの父親は
山田太郎ですか?」と尋ねなければならなかったのだ。これは、山田太郎の子供を
探すために、世界の住人すべてを走査しなければならないことを意味している。

もちろん、実際のデータベース実装では索引が利用されるため、全住人への
物理走査など発生しない。それは分かっている。ここで考えて欲しいのは、
概念としてどうかということだ。たとえ物理走査が発生しなかったとしても、
論理的には全件走査が行われたのである。DBMS は「全部調べた結果、山田太郎を
父親に持つ人達はこのだけです。」と結果を返すのだから。

「山田太郎さんに直接、子供達の名前を聞いたらどうですか?」とルーキーが言う。
「そんなことはできない。」と、あなたは笑うだろう。世界中を旅して周ることに
なんのためらいも持たないのに、本人に聞く事はできないという。
滑稽ではないだろうか。これが現在の RDB なのである。

これに気付かない人は多い。索引によって世界中を旅して周る(のと同じ結果を得る)
など、あっという間にできてしまうからだ。時間はまったくかからない。
時間はかからないけど、世界中を旅していることは理解して欲しい。


163 NAME IS NULL


04/08/25 22:26 ID:???

161
> "伝票明細 left outer join 伝票ヘッダ" としか書くことができない。

なぜでしょう?

伝票番号は明細にだけ存在して、ヘッダには存在しないということでしょうか?
良く理解できないんでどんなデータ構造と参照処理をを想定しているのか、も
うちょっと詳しく教えてもらえませんか?


164 NAME IS NULL


04/08/25 22:27 ID:???

162
> 「山田太郎さんに直接、子供達の名前を聞いたらどうですか?」とルーキーが言う。
山田太郎さんを特定するには、オブジェクト指向ではどうなるんでしょうか?

165 NAME IS NULL


04/08/25 22:58 ID:???

162
>まだ RDB の問題を理解できていないだろうと思う。
>もうひとつ例題を示そう。

どこに問題があるのか書いてもらわんと意味がわからんのだが。

166 NAME IS NULL


04/08/25 23:29 ID:???

163
もちろん記述としては、"伝票ヘッダ left outer join 伝票明細" と
書くこともできる。しかし、この記述は外部キー定義に則していない。
伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。

164
ここでは、山田太郎をポイントする方法を問題とはしていない。
OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。
たとえば、横浜市在住の40歳男性にちゃんねらDB板常駐という条件で、
山田太郎が見つかったというストーリーにしたら、満足するだろうか?
とにかく、山田太郎は見つかった。そこから子供を探したいということだ。

165
RDB ではモデル化が直接的でなくトリッキーな方法で実現しないといけないことがある、
というのが現在の RDB の問題である。これは、実装技術により速度的にはなんの問題もない。
だが、概念としての難解さを抱えているのである。

select 名前 from 住人 where 父親の名前 = '山田太郎'

もう一度、これを見て欲しい。実装や速度の話をしているのではない。
「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。

「山田太郎の子供を探す」という命題が「住人すべての中から山田太郎を父親に
持つ人を抽出する」としか記述できないのである。これは本質を、RDB の性質に
合わせて書き換えているということであり、可読性の低下をもたらしている、とも言える。

この RDB の性質に合わせた問い合わせの書き換えについては、可読性の低下だけでなく
誤った結果を得てしまうというミスにつながることも少なくない。このミスの発生については
また改めて名寄せに類似した問題で説明することにしよう。

167 NAME IS NULL


04/08/26 00:00 ID:???

166
> しかし、この記述は外部キー定義に則していない。

なんで?外部キー定義って表同士の関係(状態)を表しているもので、データ
操作における参照方向を定義したものじゃないと思ってたけど。

「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
それは参照方向の定義だ」という主張でしょうか?

> 伝票ヘッダ left outer join 伝票明細 on 伝票ヘッダ.伝票番号 = 伝票明細.伝票番号 とは、
> 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。

それで良いと思うけど。OIDならそれを回避できるわけじゃないですよね?
OIDが物理アドレスに簡単に変換できるかどうかというのはまさしく「実装」
の問題ですよね?

> 164
> OODB でも RDB でも山田太郎の属性で好きなように横断的に検索すればいい。

だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
変だと思うけど。

> とにかく、山田太郎は見つかった。そこから子供を探したいということだ。

つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
よい、ということでしょうか?


168 NAME IS NULL
04/08/26 00:25 ID:???

165
>実装や速度の話をしているのではない。
>「山田太郎の子供を探す」ための記述が上記のようになることが問題なのである。
>これは、「住人すべての中から山田太郎を父親に持つ人を抽出する」という意味である。

そうなの?実装されたプログラムの速度が問題なのかとおもってた…

速度が問題じゃないなら、あなたがやっかいさを指摘してるのは「関係代数」なのか。
そこまでくると話が発散しそうだな。たとえば行列演算や基礎物理が理解できないやつに
ポリゴン使った3Dゲームのプログラム任せられないのと一緒で、
関係代数のエッセンスをつかめないやつにRDB使うプログラム任せるなってことに
なってしまう。

それとも、ORマッピングなんて所詮ムリヤリな話だからオブジェクト指向の
大事なメリットを損ねるのよ、だからプログラムをOOでやるなら
DBもOOでやれよって話?

169 NAME IS NULL
04/08/26 00:27 ID:???

まちがえた 166 ね。

170 NAME IS NULL


04/08/26 00:45 ID:???

> なんで?外部キー定義って表同士の関係(状態)を表しているもので、データ
> 操作における参照方向を定義したものじゃないと思ってたけど。

外部キー定義とは、データ走査における(推奨される)参照方向の定義である。
これに従わないものは「辿る(外部参照)」という行為ではなく横断的検索である。
なぜなら、外部キーの性質により順方向の参照は、必ず 1件の結果となるが、
逆方向の参照結果が 1件になることは稀だからである。

> 「外部キーの設計を図に書くと矢印だ⇒矢印だからそれはポインタだ⇒だから
> それは参照方向の定義だ」という主張でしょうか?

主張するつもりはないが事実としてそうである。伝票明細は商品への外部参照を持つ。
これは、「伝票明細から売り上げた商品を知ることができる」ことを意味する。
商品から無数に存在する伝票明細への参照というのはモデル化として、おかしい。

> > 伝票ヘッダ1件ごとに、伝票明細全体からその伝票番号を持つデータを探す、ことを意味する。
> それで良いと思うけど。

「伝票明細全体から探す」ということに疑問を感じないのであれば、
私は、もうこれ以上あなたに説明するだけの言葉を持っていないということだと思う。

> だったらRDBでの例はjoinして山田太郎とその子供を見つける例を挙げないと
> 変だと思うけど。

> つまり、特定のデータ操作を想定して、それをデータ構造の中に埋め込む方が
> よい、ということでしょうか?

申し訳ないが、これらの質問の意味・意図も理解できなかった。
あなたは何をしたいのか?


171 NAME IS NULL


04/08/26 00:59 ID:???

> DBもOOでやれよって話?

これだけは否定しておいたほうがいいだろう。私はモデル化の制限について話し、
これらが実装の問題でないことを説明してきた。だが・・・今までの私の説明と矛盾するようだが、
もっとも重要なのが「実装」なのである。なぜなら、実装を差し置いて(理想的なモデル化論だけで)
システムを組み上げることはできないからである。

つまり実際に使用できる実装を考えた場合、現時点では RDB を選択するのが
もっとも良いと私自身考えている。ハンドリングが Java などの OOP であったとしても
バックエンドには、現時点で RDB を選択すべきなのである。私は OODB を推したりはしない。

ただ、いまの RDB が 100年続くとは思って欲しくない。私が指摘したように
うまくモデル化できない事象もたくさんある。これらを真面目に考えていくことは
RDB のブレークスルーになるかもしれないのだ。

172 NAME IS NULL
04/08/26 01:13 ID:???

170
私は167ではないけど、まぁもちついて。

167が言ってるのは…DBMSのメリットのひとつ

[特定のデータ操作からデータの内部構造を独立させることができ、
その独立性によって仕様変更に対する柔軟性が向上したり、
他のクエリに対しても同じような速度でアクセスできるという期待を持てる]

をあげてる。
特定の操作に対する最適化は、それはそれでアリだけど、
それを持ち出してきてRDB、というか関係代数が問題を含んでいる
というのはちと飛躍かと。

あと、1:Nの例を挙げてるけど、現実世界がN:Mになっててそれを
率直にモデリングしたい場合もあるわけで。関係代数のメリットって
それを中立的に表現できることじゃないの?

それから気になったこと。
やろうと思えば親1:子N関係でも親から子へ、子の数に関係なくリンク張れるがな。
C言語なんかではN分木を、「長男と弟へのリンク」の2分木として実装するでしょ。
それと一緒。伝票ヘッダは商品1へのリンクだけ持ってて、商品1が
商品2へのリンクを持ってればすむ。
あなたならディレクトリ構造みたいな木をどうやってコーディングするのさ?

そんでそれは、関係代数マンセーな視点からは「最適化に含まれるので
別議論である」ってこと。

173 NAME IS NULL


04/08/26 07:12 ID:???

おはよう、諸君。
あなたたちは、まだ理解が追いついていないようだ。
もうちょっと説明してあげたいこともあったのだが、的外れな質問で
話が遮られるばかりなので、ここでの説明はこれで打ち止めとしよう。
非常に残念なことである。

あなたたちには、これからももっとがんばってもらいたいものである。

174 NAME IS NULL


04/08/26 16:55 ID:???

173
あまり論点が明確化されてなくて探りを入れることになったので、質問が的を
はずしていたかもしれないのはしょうがないですね。
#全くの他人とは、あまり議論されたことが無いのかな?

私は結局論点にしたいのがモデルなのか、DB利用者にとっての実装か、DBMS自
体の実装か、利用する上でのシンタックスなのか分からずじまいでした。

もう止めるということなので残念です。どなたか170にあった「外部キー定
義とは、データ走査における(推奨される)参照方向の定義」というのが分かる
Webサイトか何か知りませんか?
#もう今の環境じゃDB関連の書籍が手元に無い、、、

私の頭の中じゃ、外部キー定義はレコードが参照して整合性を保つためのもの
で、アプリがその参照を参考にしながら逆方向に辿るのは全然OKだと理解して
た。


175 NAME IS NULL
04/08/26 19:31 ID:ps/wA+nf

外部参照制約に方向はあるよね。
逆向きに使っちゃいけないのかどうかは知らんけど。
スキーマとして依存関係を記しているというのもうなずける。
話の意味は良くわかんないんだけど、読み物として面白いから
山田太郎先生には返ってきて欲しいぞ。

176 NAME IS NULL
04/08/26 22:28 ID:???

OODBにしてもXMLDBにしても、そういう一風変わったモノは
DQNに取り憑かれ易いよなぁ。

177 NAME IS NULL
04/09/01 00:39 ID:???

あそれ~♪
D どんな
Q クエリも
N ぬるぽで返す~
ときたもんだ
  ∧_∧
 ( ´∀`) <ぬるぽ

178 U </b>◆CZtFsGiu0c <b>
04/09/03 12:44 ID:???

最近知ったのですが、ObjectCacheってバックエンドがRDBでも使えるのですね。
分散環境で高速参照が必要なところで使ってみると面白いかも。

179 NAME IS NULL
04/09/21 23:58:35 ID:???

遅レスだが
178 は @it の記事のことですかな?
私はいまODB勉強中なのですが、
確かに面白いかも…

しかし、ううむ…。あの記事、なんか論調として
・RDBを扱える技術者は豊富
・RDBは壊れたときのリカバリなど実績がある
・間にはさむキャッシュとしてObjectCacheをつかうと速くてウマー
というように読めたのだけど、それって、
RDBでスピードが出なかったときの
最適化の選択肢なのかな?いやまてよ、
ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの?
と、なぞが深まりますた。

ObjectCache使ったアプリ書いたひといる?
アプリの書き方変わらんの?

180 NAME IS NULL
04/09/22 06:52:16 ID:???

最近のシステムではRDBアクセスをEJBで隠蔽しているものが結構あると認識していますが、
これって、EJB-RDBひとまとめにしてDBと考えると、
「EJB+RDB=OODB!! カモンOODB!!」
などと思うのですよ。
本業で扱うデータが素直に正規化できないわ、素直に検索できないわ、ってな性質があるので、
データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
何かないでつか。

181 NAME IS NULL


04/09/22 13:24:32 ID:???

age

182 NAME IS NULL


04/09/22 14:45:41 ID:???

180
> これって、EJB-RDBひとまとめにしてDBと考えると、
> 「EJB+RDB=OODB!! カモンOODB!!」
> などと思うのですよ。

RDBとOODBはデータモデルの違いのほかに、「サーバのモデルをアプリで利用
する」か「アプリのモデルをサーバに入れるか」というアーキテクチャの違い
が暗黙的にあると思うので、いわゆる従来の「OODB」とは異なってくるんじゃ
ないでしょうか。

> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
> 何かないでつか。

MATISSEが多少近いかもしれません。meta-schemaをいじれるようになっている
らしいので。

しかし、ユーザに提供しているインタフェースと、DBMS内のモデル・検索処理・
トランザクション管理・排他制御・ディスクページ内レイアウト・ロギングが
密接に関連しているので、完全にフリーにするのは難しいと思います。

RDBやOODBで作られたものをXML対応にしてさらに全文検索にも対応、という場
合には大抵ライブラリやラッパーをかぶせて実現しています。

無理やり実現しようとすると結局ファイルシステムと大差ないものになってし
まう気がします。


183 180
04/09/23 01:09:56 ID:???

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

184 NAME IS NULL
04/09/23 14:15:13 ID:???

180
> データモデル、検索エンジンをフリーにできるDBMSがあったらいいなと思うのですが、
フリーって何のことか補足キボンヌ

185 U </b>◆CZtFsGiu0c <b>
04/09/23 14:30:48 ID:???

179
>@it の記事のことですかな?

そう。ObjectCache自体はソニックのサイトで前から知っていたんだけど、Rdbをバック
エンドに使えるとは知らずスルーしていました。

>ObjectCacheかましたらアプリケーションの
書き方変わるんじゃないか…
じゃあ最初から使うつもりでないといかんの?
と、なぞが深まりますた。

まず現状O/Rマッピングをどうするか、てのが問題になってるわけだよね。
ObjectCacheをO/Rマッピング+データキャッシュと考えると、アプリケーションレベルで
O/Rマッピングを考える必要がないのと、通常のO/Rマッピングでは、どうしてもパフォー
マンスを考慮してモデルを崩したりSQLを自力で書いたりしなければならない部分を解決
できるんじゃないかな、と思います。


186 180
04/09/23 14:58:35 ID:???

184
交換可。データモデル等からある程度自由になりたいの。
プラッガブルとか書いた方が良かったかな。

187 NAME IS NULL


04/09/24 17:47:46 ID:???

183

EJBとかをいじくり倒したことはないので噛み合ってないかもしれませんが。

> ラッパーまで含めて、DBと見なしたら楽になるかな、という話です。
> oo的にはInterfaceが一緒であればいいかな、と思ったのですが。

もともとDBMSの類はデータを公開して共有しよう、というところから生まれて
いるので、OOのカプセル化のようにアプリのソースの変数管理方法とはそのま
ま当てはまらないところもあると思います。

カプセル化する利点はデータモデルを自由に変更できるところにあるとしても、
いったんDBに格納した過去のデータは簡単には変更できないという違いもあり
ます。(プログラムの場合は電源を切っちゃえば無かったことにできるけど)

アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
利かもしれません。

アプリ<->EJBのインタフェースをデータモデル非依存にするとしても、

・モデルおよび各種名称(クラス名とか属性名とか)に非依存なインタフェース
をどうやって定義するのか。
・EJB<->DBMSのところでは、中に入っているシステム特有の名前を扱う部
分が自動生成できるかどうか、それが公開インタフェースにマッチできるかどうか。

辺りが悩ましそうです。考察するのは面白そうだけど

パッケージや製品として世の中に出す場合には、システム非依存にしなければ
ならないところも難しい点だと思います。
逆に言えば業務を特定したものであれば、そうした解は出てくる気がする。
(それも特定の業務「モデル」に縛られることにはなるけど)

#勘定奉行がバージョンアップ時にストレージレイヤを入れ替えるとかかな?SAPもそうだっけ?


188 180
04/09/25 04:25:00 ID:???

あう。凄く誤解させてしまったかも。スマソ。
187
>アプリケーションやそれが利用するインタフェースが固定で、DBMSのみ入れ替
>えるという事例はいまひとつピンと来ませんが、もしそういう場合であれば便
>利かもしれません。
入れ替える、というのが不適切な表現だったようです。
想定している応用はこんな感じです。
1.膨大な(公開された)フラットファイルのデータがあって、ホモロジー検索をかけたい。
2.自分のところで作ったデータのうち正規化できるものは、RDB/OODBに入れて検索したい。
3.xmlなグラフデータも検索したい。
4.検索結果をオブジェクトとして受け取りたい。
ですので、入れ替えるというよりは組み合わせて使うような。

それだとデータモデル横断的な検索とかできないから何かないか、
というのが180の後半です。
やっぱり
182>ライブラリやラッパーをかぶせて実現
とかObjectCache'とかじゃないと余計悩ましそうですね。

189 NAME IS NULL
04/09/26 11:38:40 ID:K2xHeQ+O

とりあえず現在ObjectStoreを使っているけど、全然メリットを感じない。
クラスへのフィールド追加時に、データのエキスポート、インポートをしなければ
ならないんじゃ実運用に耐えない。

ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのRDBでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。

またRDBであれば、他システムとの連携が簡単(ODBC,EAIなど)だが、インタフェースが
独自のODBではそれも難しい。

ツリー構造をそのまま格納出来るのは、開発時は楽だけどテストデータの作成や
保守運用時には全然メリットを感じない。

ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。

しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。

分散キャッシュでのスケールアウトもOracleのRACの方がまし。

ということでODB全般は知らないけど、少なくともObjectStoreを使うメリットは
全く感じられない。

190 U </b>◆CZtFsGiu0c <b>
04/09/26 19:33:12 ID:???

189
(今までの書き込みを見てもらえばわかるけど)大半は同意。

>ObjectStoreはメモリキャッシュを売りにしているけど、RDBもキャッシュを持っているし、
高速機関などのRDBでもメモリキャッシュを実現しているので、MRAMやRRAMが
いずれ実現する事を考えると少なくともObjectStoreのメリットはない。

サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?

>ODBだとRDBのモデリングが必要ないみたいなのをたまに聞くけど、クラスモデリングが
必要だから工数は全然変わらない。

いや、クラスモデリングに加えてデータモデリングが必要だったり、RDBを使うために
クラスモデルを崩す必要があったりするのが問題なのでは? とはいうものの、現状では
OODBを積極的に使うほどのメリットには思えないけどね。

>しかも独自キャッシュのチューニングとかが大変なので、最近パフォーマンス
チューニングが自動化してきたRDBと比べると全くメリットなし。

キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
クラスタへの配置とか?

191 NAME IS NULL
04/09/26 21:33:13 ID:K2xHeQ+O

>サーバ側のキャッシングとクライアント側のキャッシングでは意味が違うでしょう。
>メモリ技術の進化も、ネットワーク通信のオーバヘッドとは直接には無関係では?

クライアント上のキャッシュと言っても、実質APサーバ上でのキャッシュなので、
APサーバとDBサーバが統合されてしまえば、全く問題なし。
特に最近はDBサーバ上のストアドが高級言語になりつつあるから、余計ODBの
メリットが少なくなる。

CPU技術が、これからマルチチップ、マルチスレッド+仮想化進むので、
わざわざサーバ台数を増やすクライアントキャッシュの必要性はないし、
運用保守費が増加するだけと思います。

>キャッシュのチューニングってなんでしょう? キャッシュサイズの調整とかオブジェクトの
>クラスタへの配置とか?
クライアントキャッシュのサイズなどです。
確かにいろいろ最適化してくれているようだか、そのせいで実際の速度が分かりにくい。
キャッシュにないと遅いけど、突然早くなったりで動作速度が読みにくい。

ObjectStoreは、クライアントキャッシュでのスケールアウトが売りだけど、
それはRACでのスケールアウトでも達成可能。
でもこれはあくまでObjectStoreの話で、ODB一般の話ではないですね。

個人的には、SQLServer2005のようなストアドの高級言語化の方が、
ODBよりも良いと思われる。
ChacheのようなアプローチもObjectStoreよりかは良いですね。

いずれにしろ自分が良く関係する業務システムでは、ポインタ検索より
値検索の方が多いので、ODBの出番はない。


192 NAME IS NULL


04/09/27 17:56:40 ID:???

188
> それだとデータモデル横断的な検索とかできないから何かないか、
> というのが180の後半です。

なるほど。
昔はネットワーク型DBとRDBのインタフェースを統一する試みもあったみたい
だけど、頓挫したのか普及しなかったのか、、、

今はそれ以上にいろんな検索がありえるし。
全部共通にしようとすると、ID指定検索ぐらいしか無いような気もします。で、
後はアプリケーションでがんばってね、とか。

結果となるオブジェクトの機能がどうなっているべきかを設計するのも難しそうですね。

・バックエンドはRDB/XML/全文検索/LDAP/UDDIぐらいを想定
・インタフェースはOODBを参考に
・引数等で各バックエンド固有の機能を記述することは極力避ける

というものを設計できればよいんだけど、簡単に出来るぐらいなら今この仕事
はしていないなw
.NETとかは一応この方向を目指してるんだっけ?


193 NAME IS NULL


04/09/27 18:18:48 ID:???

191
ほぼ全面的に同意ですが、

> クライアント上のキャッシュと言っても、実質APサーバ上でのキャッシュなので、
> APサーバとDBサーバが統合されてしまえば、全く問題なし。

性能の面やセキュリティの面で、将来統合することが主流になるとは(まだ)思
えないです。

また、もともと今のアーキテクチャもRDBのアーキテクチャを前提にしたもの
なので、それにOODBがそぐわなくなってしまっているのもちょっと同情する所です。

OODB屋の発想は「プログラムのソース(の書き方)がすべての出発点」で、それ
に合うアーキテクチャを結局提示できなかったり、主流になれなかったのが痛
いですね。

HTMLやXMLはRDBよりもOODBにマッチする、と主張して失笑を買っていた記憶し
かないですし。

ObjectStoreにはActiveX対応版もあったと思うのですが、どういう構成で動作
したんだろう?


194 NAME IS NULL
04/09/27 22:21:11 ID:???

オブジェクト指向でシステムを設計すると、多態性のあるオブジェクト群をひ
とつのコレクションにたくさん格納するとか、そういうデータの持ち方がよく
出てくるのですが、そいういった似て非なる情報群をRDBで管理しようとする
と1インスタンス=1レコード といった単純な格納の仕方が通用しなくなる
ので、かなり頭をひねらなくてはならなくなると思います。

そういったことを考えると、ODBといったものの方が自然に扱えていいと思う
のですがいかがですか。


195 NAME IS NULL


04/09/28 13:23:11 ID:???

194
ところが、従来OODBが格納するものはオブジェクト指向設計ではなく、オブジェ
クト指向言語でプログラムしたものの実行イメージです。ObjectStoreは特に
そうだし、他のOODBもそれを志向しています。

そのためプログラミングは便利になるかもしれないけど、システムを稼動させ
たときの運用などにしわ寄せがよってしまいます。

どちらがクリティカルかといえば、動かしたときの方だと思います。


196 NAME IS NULL
04/09/28 15:32:32 ID:???

195 うーん、そうなんですか。

- オブジェクトをアプリケーションから透過的に永続化したい

というニーズと

- オブジェクト指向設計に即したデータストアのインフラが欲しい

というニーズは似て非なるものですよね。
現行の製品はもしかすると前者からスタートしているのでしょうか。
だとすればあまり魅力を感じません。
むしろ欲しいのは後者です。今後に期待したいですね。


197 NAME IS NULL
04/09/28 17:25:43 ID:???

196
ZopeのZODBなんかは、前のやつそのものって感じですね。

198 NAME IS NULL
04/09/28 18:00:58 ID:???

197
Zopeはちょっとしかかじってませんが、ZODBもPythonのDictionaryの
ように扱える反面、Pythonからしかアクセスできないみたいですね。

データベースに格納したオブジェクトが、例えばCORBAのような
汎用のインターフェースを通じてリモートオブジェクトとして
アクセスできるような製品はないんでしょうか。


199 NAME IS NULL


04/09/28 19:30:14 ID:???

198
CORBAからODMGへは規格上は繋がったはず。ODMGの言語バインディングに対し
てCORBA側が対応したのかな?

だけどRDBやそのほかのStorageに対してどんなものが用意されているかはよく
知りません。

そもそもPOS自体が企画倒れになったらしいから、あまり(CORBAとしては)力
を入れてないのかも。モデル間マッピングの泥沼にはまり込むのを避けたのか
な。分散トランザクションもややこしいし。


200 NAME IS NULL
04/10/12 15:42:35 ID:???

199
遅レスですみせん。
ODMG, POSという言葉を知らなかったので調べてました。

POSも後継のPSSも、あまりWeb上に新しい情報がないみたいですね。
CORBA自体が下火だからでしょうか。


201 NAME IS NULL


04/10/13 17:13:49 ID:???

200
> CORBA自体が下火だからでしょうか。

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

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

Entity BeanやEJBの分散トランザクション管理機能(DBMSにdispatchするだけ
じゃなくて)がここまで進化した、というような話はあるでしょうか?


202 NAME IS NULL
04/11/25 18:55:24 ID: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でコスト削減と性能向上が可能なわけでつか?

203 NAME IS NULL


04/11/26 11:10:13 ID:???

202
> 理由が書いてないけど、OODBでコスト削減と性能向上が可能なわけでつか?

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

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

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

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

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

ところで、ObjectStoreっていつの間にか買収されてたんですね。3年ぐらい前
はXMLブームに乗って「今後はXMLに特化した製品・会社になる」と宣言してい
たような気がしたんですが、最近はEC・リアルタイムに特化なんでしょうか。


204 NAME IS NULL
04/12/02 00:53:48 ID:???

Cach?を使ってみたいのに、手早くMySQLに逃げてしまう漏れ。
自宅ではMacOSXなので動かん。どうしょ。

205 NAME IS NULL
04/12/15 00:08:43 ID:???

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はニッチな市場しかないじゃないかな。



206 NAME IS NULL
04/12/15 23:12:48 ID:eJ+2vIrC

質問なんですが、OODBに格納されているデータを覗くには、とにもかくにもプログラムインターフェイスを介さないと見れないのでしょうか?
OracleのSQL*Plusとか、それこそAccessみたいな感じのビューワってあるんでしょうか?
(簡単にデータの格納状態がエビデンスとして見れるツールがないと開発には使えない)

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



207 NAME IS NULL
04/12/15 23:14:53 ID:eJ+2vIrC

あと32にも書いてあるが、クロス言語を実現できる製品はあるのでしょうか?
例えばOODBの提供するinterdaceを実装することで、複数の言語への(ある程度の)マッピングをOODB側が
自動的に行ってくれるとか。
そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
後はそのオブジェクトに対するシリアライズ/デシリアライズのラッパをかますのと大差ないような気がします。


208 U </b>◆CZtFsGiu0c <b>
04/12/16 12:14:07 ID:???

205
RDBで分散キャッシュができれば、現状のOODBの意義はほとんどないと思います。

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

207
Objectivityは言語非依存のようです。また、Cacheもそうですよね。

209 NAME IS NULL
04/12/17 01:07:40 ID:???

OODBってさ、問い合わせ方式は、やっぱり所謂Dictionaryのように、一意のキー(GUIDのような)で
関連付けたりするの?
あと関係型(RDB)のSQLや階層型(例えばXMLDB)のXPathに相当する問い合わせ言語がないというのは
むしろOODB的にはデメリットだと思うんだけど。
条件付きの検索というのは業務では必須だし、そもそもユニークIDだけで一意にモデリングできるものって
世の中にはあまりない。

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

ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。


210 NAME IS NULL


04/12/20 19:34:13 ID:???

209
> ここらへんは80番台で議論されているようだけど、やはりOODB共通の問い合わせ言語というのがほしい。
> もっとも今さらOODBベンダが手を取ってOQLのような統一言語を制定するという可能性は低いと思うけど。

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

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

でもそれじゃ使いづらいから各社とも付けてますが。
さすがにアーキテクチャ上一番なじみにくそうなObjectStoreでも属性値を指
定して全件検索することぐらい出来るんじゃないかな。


211 NAME IS NULL


04/12/20 19:42:09 ID:???

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

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

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

「Inspector」を使うためには開発したクラス定義ファイルを読み込ませてや
らないといけなくて、Inspectorの中ではかなり高度なことをやっているのかな。


212 NAME IS NULL


04/12/20 19:57:25 ID:???

207
> そういう機能がなければ、はっきりいってそれこそ普通のRDBにシリアライズしてつっこんで、
> 後はそのオブジェクトに対するシリアライズ/デシリアライズのラッパをかますのと大差ないような気がします。

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

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

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

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

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

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

#OODBがあんまり好きじゃないから、ひどい言い方になってるなぁ、、、


213 NAME IS NULL
04/12/28 11:16:29 ID:???

212
オブジェクトの永続化は変数の保存とかファイルのセーブなどとは
違う水準の発想だと思うけど。

「オブジェクト」はコンピュータを使う前から現実に存在している
もので、オブジェクト指向設計はそれをコンピュータでどうやって
管理するか、という考えだし。:-)


214 NAME IS NULL
04/12/28 18:55:28 ID:???

213
>「オブジェクト」はコンピュータを使う前から現実に存在している
いやーそういう原理主義は今は流行ってないよ。


215 NAME IS NULL
05/01/07 10:00:37 ID:???

でもデータ中心主義者のいう「エンティティ」と
オブジェクト指向主義者のいう「オブジェクト」って
似たり寄ったりの概念だよね


216 NAME IS NULL


05/01/07 20:25:08 ID:???

213
コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。

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

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

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

#クレクレ君ですいませんが。


217 NAME IS NULL
05/01/12 22:36:21 ID:kc5XMLkY

http://www.db4o.com/

キタ━(゚∀゚)━!

218 NAME IS NULL
05/01/13 18:37:36 ID:???

組込み用データベース?

219 NAME IS NULL
05/01/19 04:16:16 ID:???

OODBって問い合わせ言語は何使うの?
SQLじゃないよね?

220 NAME IS NULL
05/01/19 10:25:43 ID:???

sqlも限定的に使えるのもあったんじゃなかったかな。
cacheかな。何せ使った事がないもんですみません。

221 U </b>◆CZtFsGiu0c <b>
05/01/19 16:12:01 ID:???

219
OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。

222 NAME IS NULL
05/01/19 18:26:09 ID:???

ODBってJAVAのbeanをそのうシステムが1つあるけど、必然性を感じない)

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

逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。


223 NAME IS NULL
05/02/22 18:01:16 ID:???

225 227 228 229
オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。
SQLは集合の性質を記述するもの(内包的な定義)。

224 NAME IS NULL
05/02/22 21:17:42 ID:???

もっと続けて、ハイ!!

225 NAME IS NULL
05/02/23 01:22:10 ID:???

225 商用システムでオブジェクトという概念を最初に持ち出したのが
システム38ですね。良かれ悪しかれ興味深いマシンでした。

226 NAME IS NULL
05/02/26 23:32:58 ID:ZSke6ZFq

いろいろ異論はあろうが、ざっくりと「オブジェクト=データ+手続き」と定義する。

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

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

単にオブジェクトデータベースを使うだけならいつでもできるが、
広い普及はまだまだ無理な状況にある。

227 NAME IS NULL
05/02/28 02:20:11 ID:bYwMEZoh

BFS1.0やWinFSってRDBだよねぇ。OODBがFSになるのはいつの日か・・・

228 NAME IS NULL
05/03/02 00:32:49 ID:???

OODBなファイルシステムっていまいちイメージがつかめんが、
Newtonのsoupとか、BTRONみたいなものかな?

229 NAME IS NULL
05/03/20 23:15:49 ID:2uyd6Lyh

"> 234
データはオブジェクトごとに異なりますが、手続きは変わりませんよね。
オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。
また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、
むしろ手続きは永続化対象外でであるべきかと思います。

データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル
モデルに変換するひつようがないのであれば価値があると感じます。


230 NAME IS NULL
2005/04/02(土) 11:19:43 ID:???

RDBMSで現実的なシステムを組むために
ストアドとかトリガみたいな機能が必要になったことが、
データと手続きが不可分であることを表していると思うのだが


231 NAME IS NULL


2005/04/04(月) 17:07:52 ID:???

久々に書きこもう。

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

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

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

OOな人の目的ってやっぱりプログラミング?


232 U </b>◆CZtFsGiu0c <b>
2005/04/05(火) 16:06:19 ID:???

239
よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに
違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって
OODBを使いたがるとは限らないよ。

233 NAME IS NULL


2005/04/05(火) 17:28:25 ID:???

240
ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

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

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

このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん
ですが。


234 U </b>◆CZtFsGiu0c <b>
2005/04/05(火) 17:57:39 ID:???

241
>ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。

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

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

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

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

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

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

235 NAME IS NULL


2005/04/05(火) 18:45:37 ID:???

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

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

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

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

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


236 U </b>◆CZtFsGiu0c <b>
2005/04/05(火) 19:28:39 ID:???

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

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

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

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

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

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


237 NAME IS NULL


2005/04/06(水) 15:26:15 ID:???

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

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

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

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

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

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

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

以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと
思います。


238 U </b>◆CZtFsGiu0c <b>
2005/04/06(水) 20:17:50 ID:???

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

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

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

特に反対することはないんですが、やはり誤解されていると思います。
OOでやってもエンティティはフローズンスポットになるのでそんなに
変更は入りませんし、既存のシステムは当然考慮しますよ。


239 NAME IS NULL
2005/04/07(木) 11:33:07 ID:???

つかってはみたが・・・

なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・
まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・

240 NAME IS NULL
2005/09/17(土) 05:08:39 ID:???

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試してみたらなかなか使いやすかった。
でも誰も使ってない予感


241 NAME IS NULL
2005/09/19(月) 07:51:19 ID:C0eamAh/

で、複雑で大量の事象と空間をシミュレーションするのに
今現在はどの組み合わせのシステムがベストなの?


242 NAME IS NULL
2005/09/19(月) 07:55:19 ID:C0eamAh/

多種多様のドキュメントを管理するには何がベスト?
業務処理するには何がベスト?

243 NAME IS NULL
2005/10/10(月) 01:31:00 ID:+XVZSTvE

ObjectStoreは,かつてのOO指向のイメージからリアルタイムデータ処理へと変貌した。

244 NAME IS NULL
2005/11/13(日) 10:27:14 ID:???

たとえば「注文」オブジェクトがあるとする。

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

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

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

OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに
変更があったらどうするんだろう?

245 NAME IS NULL
2005/11/13(日) 17:50:39 ID:???

マスタデータを表すオブジェクトを更新するだけじゃないの?

注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト


246 NAME IS NULL
2005/11/13(日) 18:45:27 ID:???

ということは、注文オブジェクトの方には、商品マスタオブジェクトのキーを保持
するってこと?

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

って感じ? これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。

247 NAME IS NULL
2005/11/13(日) 20:49:01 ID:???

キーっつうか、マスタオブジェクトへのリファレンスだろ?保持するのは。

248 NAME IS NULL
2005/11/14(月) 01:37:46 ID:???

ごめん。いまいちイメージがわかないや。

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

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

ってのを当初考えてたんだけど、これじゃ駄目だよね?

249 NAME IS NULL
2005/11/15(火) 18:25:16 ID:???

いいんじゃね?

250 NAME IS NULL
2005/11/15(火) 22:52:49 ID:???

それがまさにOODBってことなんだと思ってたんですが。
使ったことねえものわがらん。

251 256
2005/11/15(火) 23:26:19 ID:???

当初それで考えてたんだけど、たとえば Product.Name が変更された
とするよね、永続化されてる Order クラスには、それがわからないと
思うのですよ。

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

XML への永続化とかだと、そうはならないんで、すっかり誤解してました。

252 NAME IS NULL
2005/11/16(水) 13:30:38 ID:???

クラスという言葉はまぎらわしいからオブジェクトと言ってくれ。

実装によって細部は異なると思うけど基本的には
productオブジェクトもorderオブジェクトも、
どちらも永続化されていて、永続化されたDBの中で参照関係が
保持されていると考えるのが普通じゃないかと。


253 NAME IS NULL
2006/03/21(火) 13:12:52 ID:???

保守

254 NAME IS NULL
2006/04/04(火) 11:09:47 ID:???

259
それはヤバイ。製品仕様が変更になって、商品名が変わったときに、
以前に受けた注文の商品名が変わってしまうと、商売上、会計上
無茶苦茶になる。

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

どれを選ぶかは、業務次第。

255 NAME IS NULL


2006/04/14(金) 18:19:57 ID:???

保守

256 NAME IS NULL
2006/06/03(土) 17:13:50 ID:???

db4oのアンケート答えたら本が当った、わーい。
実はまともに触ったことないけど、
届いたらじっくり読んで遊んでみることにするよ。

英語苦手だけど。

257 NAME IS NULL
2006/10/01(日) 16:47:44 ID:raj0JmDs

J○1なんて、変更多かったりいろんなベンダー絡んでくるWEB系噛んでくると当然だが、まったく使えない。
「どうやって直しゃいいーの?やりようねーよ。」って・・・hahaha
でもって塩漬け

258 名無しさん@お腹いっぱい。
2006/12/04(月) 10:38:56 ID:nny60kaK

関連wiki
http://wiki.ninki.org/wiki.cgi?p=OODB+%2d+%a5%aa%a5%d6%a5%b8%a5%a7%a5%af%a5%c8%bb%d8%b8%fe%a5%c7%a1%bc%a5%bf%a5%d9%a1%bc%a5%b9


259 NAME IS NULL
2007/01/13(土) 22:57:22 ID:CL7OUlxj

OQLを使える組み込み可能なOODBって何がある?

260 NAME IS NULL
2007/01/17(水) 00:28:55 ID:???

ラムダDBとか。つかちょっとは調べろや

261 NAME IS NULL
2007/01/17(水) 16:54:49 ID:???

268
すまん
Javaのやつを探していたのでスルーしてた

262 NAME IS NULL
2007/01/17(水) 16:58:21 ID:???

db4oがOQL使えれば最高なんだがな・・・NQってなんだよorz
コンパイル時にチェックできてもポータビリティがないじゃないか

263 NAME IS NULL


2008/06/21(土) 22:54:09 ID:???

保守

264 NAME IS NULL
2008/06/22(日) 19:52:26 ID:???

db4o、色々実験してみて気に入った。
仕事でも趣味でも使ってる人います?

265 NAME IS NULL
2008/06/24(火) 01:16:29 ID:hnzrfZsh

272

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



266 NAME IS NULL
2008/06/24(火) 02:45:42 ID:???

273
本格的なプログラムの場合はDAO作った方がいいよ。
海外だと弄ってる人多そうだけど、日本は少ないね。

たしかリコーと提携して何かやるとかって話があったけど、
どうなったんだろう。

267 NAME IS NULL
2008/06/25(水) 08:20:07 ID:TGcEK7R9

274

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

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

しかしよくエンタープライズで使う気になるよなぁ

268 NAME IS NULL
2008/06/25(水) 17:34:38 ID:???

日本は盛り上がらんね。
日本語の開発者向けフォーラムもさっぱりだし。

リコーはエンプラじゃなくて組み込みじゃないかな?

269 NAME IS NULL
2008/06/25(水) 19:43:52 ID:TGcEK7R9

276

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

組み込みなんだ?

自社製品になら納得。



270 NAME IS NULL
2008/08/12(火) 23:38:20 ID:???

277
サンプルってpdf読んだ?pdf+あっちのフォーラムで解決出来るよ。

Dao作ってる人はQBE?NQ?SODA?どれベースにした?
ソートとか考えるとSODAしかないのかな・・・

271 NAME IS NULL
2008/08/12(火) 23:53:41 ID:???

って1ヶ月前が最終レスか・・・やっぱSODAに行き着いたら離れてくか

272 NAME IS NULL


2008/08/13(水) 07:50:09 ID:???

最近さっぱりいじってないけど、俺はNQ
でもSODA併用にすると思う
NQを完全に捨てた場合は、離れたくなる気持ちも解る…

実はQBEが一番好みなんだが、単純なクエリにしか使えない

273 NAME IS NULL
2008/08/17(日) 13:37:16 ID:???

280
全部のエンジン対応のBaseクラス実装してみた。
・・・Update、Deleteがスマートになった位。

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

・・・やっぱりH2+O/Rでいいやw

274 NAME IS NULL
2008/09/04(木) 06:17:39 ID:Jasyu6Tw

Google Chrome + Google Gears 大人気だなw

Object Store Personal Edition で時代を切り開こうとしてたJava厨涙目www

275 NAME IS NULL
2008/11/09(日) 03:10:17 ID:gH6xlPae

ちと質問。
OODBならGBのファイル管理も余裕ですよ!と謳っているけど何で?
DVDから直抜きしたエロ動画コレクションをOODBで管理すると仮定して
神イグザンプルを教えてエロイ人!!!

276 NAME IS NULL
2008/11/09(日) 08:58:10 ID:???

1件のデータが非常に大きいとしても、件数が数千、数万ならOODBでも余裕じゃね?
RDBじゃ無理とか言ってなければ別に嘘じゃない。

277 NAME IS NULL
2008/12/11(木) 11:45:03 ID:???

db4objects がデータ管理ソフトウェア Versant に DB db4o 事業を売却
http://japan.internet.com/linuxtoday/20081208/5.html

278 NAME IS NULL


2010/02/27(土) 02:58:52 ID:???

KVSよりかはこっちにがんばって欲しいもんだが…

279 NAME IS NULL
2010/04/23(金) 08:21:04 ID:iFVUkXwP

まだOODBって業務で使えるレベルではない?

280 NAME IS NULL
2010/04/23(金) 19:33:40 ID:???

287
現に使われてるだろ

281 NAME IS NULL
2011/01/10(月) 22:42:41 ID:PKlMUoys

O/RマッパーとかいうクソみたいなFWが流行っちゃってるから
とっととOODBをもっと広めろやアホども。

282 NAME IS NULL
2011/01/13(木) 10:02:25 ID:???

またおまえか

283 NAME IS NULL
2011/01/21(金) 00:26:36 ID:???

「またおまえか」
じゃねーよ。
しっかり広めろ。

284 NAME IS NULL
2011/01/21(金) 11:47:08 ID:???

よし">291に任せた!

285 NAME IS NULL
2011/03/16(水) 12:29:11.83 ID:+4v+dlKX

PHPで使えるSQLiteのような手軽なOODBない?

286 NAME IS NULL

sage

2011/03/26(土) 19:51:40.99 ID:???

継承できればオブジェクト指向というのは違う。
メッセージを送ってメソッドを呼び出せないなら
オブジェクト指向型じゃない。

287 NAME IS NULL
2011/05/24(火) 23:55:55.53 ID:xKicDgVR

294
だからSQLiteのような手軽なOODBが無いかと言ってんの。
OK?

288 NAME IS NULL
2011/05/26(木) 06:07:49.44 ID:???

ないない。
無いからお引き取りください。

289 NAME IS NULL


2012/09/09(日) 20:09:28.24 ID:???

age

290 NAME IS NULL
2015/03/09(月) 12:02:47.05 ID:???



291 NAME IS NULL
2016/01/07(木) 00:20:03.13 ID:PXFmI/6O

今までに無い全く新しい手法!
http://goo.gl/ogJo8a

292 NAME IS NULL
2017/03/21(火) 21:42:16.07 ID:???

http://www.doraibu.com/ どらいぶ帳よろしく

293 NAME IS NULL
2017/04/15(土) 06:27:52.60 ID:PAxoNq0R

realmはここでいうオブジェクトデータベースになる?

294 ich1
2017/04/21(金) 16:36:29.64 ID:R/eXxgbc

https://goo.gl/q9Ml0S
これは嘘でしょ?本当だったら落ち込むわ。。

295 NAME IS NULL
2017/12/29(金) 11:40:58.19 ID:dtNZwIie

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

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

66CFHAV81O

296 NAME IS NULL
2018/02/14(水) 13:34:08.01 ID:???

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

297 NAME IS NULL
2018/09/07(金) 21:46:35.74 ID:u0dGdBIY

まだあったのか
ここでバトルしたのも15年も前か

1 2 3 4 最新200 全部見る 


人気スレッド

58: 日経225先物オプション実況スレ35525 (907)
16: 【対韓輸出規制】韓国のフッ化水素、日本からの8月の輸入量がゼロに 代わりに台湾の輸入量が6倍に増加 ★5 (73
1161: 【セブン計算方法変更】Q.税込100円のコーヒーを3つ買ったら合計何円? A.301円 (679)
3: 【日韓関係悪化】対馬の韓国人需要に賭けた在日資本が大損害を被って撤退 費用を賄えないと悲鳴を上げる在日二世 (66
1162: 【讃岐うどんの定義】麺通団団長「気分が悪い」、「丸亀製麺」めぐり“香川うどん論争”が勃発★4 (583)
981: 【ネット】ひろゆき「貧乏になった人はリアルでバカになり、ムチャクチャな方法でカモられる」 (553)
2: 【前時代の決済システム】QRコード決済“まさか”の落とし穴 中国では犯罪が急増 ウイルスが仕込まれることも (43
7: 【投影】韓国、日本を輸出優遇国から除外 「国際的基本原則に反して制度運用する国とは協調できない」 (430)
980: 【速報】楽天平石監督が退任へ 後任候補に三木2軍監督ら (400)
975: アホガキ3人「ヒャーハー!強盗ダー!」→狙われた家の住人男性が反撃して3人とも射殺 突撃銃を乱射か (397
991: 【野球】イチロー氏、今オフ草野球デビューへ!エース兼監督兼オーナー、神戸で伝説第2章 (388)
1136: 大阪に最大級アリーナ誘致 吉村府知事「少なくとも1万5千人以上、横浜アリーナ以上を考えている」 (383)
991: 日本への韓国人観光客減少で韓国イースター航空が非常事態宣言 3ヶ月の無給休暇 (371)
979: 日本人のアルコール離れ 逆に炭酸水は過去最高 (351)
20: 【韓国】 市・道議会議長ら 「日本戦犯企業不買条例を中止しよう」 [09/18] (345)
982: 福島の汚染水全部東京湾に流せばよくね?ただの水なんでしょ? (329)
1012: 【MHW】モンスターハンター:ワールド HR1470 (290)
974: これを真顔で言うからたまげる 「日本の韓国除外は違反だが、韓国の日本除外は規定に準拠している」 (290)
1016: 【中央日報】有事の際の韓半島増援戦力69万人の国連軍はだれが指揮?[9/18] (283)
994: 台風15号 政府初動対応に批判=内閣改造で「空白」 (^ν^消費税延期決断したら許してやろうず (211)
7: 【経団連】政府の就職氷河期対策、効果検証を…雇用保険の財政悪化警戒、安易な積立金の取り崩しにくぎをさす ★2 (1
979: 【音楽】スガシカオ『日光アレルギー』を告白 「キツかった」 (189)
1003: 「分譲マンション」って「一軒家の欠点」と「賃貸の欠点」しかなくね?どんな馬鹿が買ってるの? (188)
1007: 【FEH】ファイアーエムブレムヒーローズpart4937 (174)
1178: 【常識】新聞投稿「1円玉の悲しみ」が話題 おじいちゃん、75枚払い、店員に「営業妨害」といわれ立腹 (170
1149: 【消費税増税】元財務官僚 ?橋洋一氏「消費税引き上げは本当は必要ない」 (161)
1001: 【テレビ】<浜田雅功>次男が大学卒業! 高校はアメリカ…妻・小川菜摘が報告 (160)
1000: 日本人ってなんで韓国に憧れてしまうんだろうな?やはり「血」なのかねぇ (159)
999: 【女優】新木優子、恋人のような距離感にドキッ! セカンド写真集発売決定 水着ショットも (149)
976: 【音楽】岡田有希子さんアルバム10月発売 竹内まりや追想 (148)
19: 【ソウル新聞】『新聞記者』#望月衣塑子に注目・・・「日本メディアの象徴」[09/18] (145)
1166: 【米国】トランプ大統領、ボルトン氏後任にケロッグ氏らを検討 (145)
986: 白髭神社の鳥居を破壊。琵琶湖の水上バイカスどもの狼藉。神罰当たって苦しんで死ねカス馬鹿ボケカス (144)
985: 日本「EEZに北公船が不法侵犯、厳重な抗議」北朝鮮「EEZに海保巡視船が不法侵犯、厳重に抗議」 (144)
1126: 【東電からのお知らせ】千葉県の停電、27日までにおおむね復旧します (144)
985: 【サッカー】UEFA-CL第1節 南野が2アシスト!伊東との日本人対決制す!奥川も出場のザルツブルクが大勝 (
1125: 【スマホ】サムスン「ギャラクシーノート10」 韓国販売が最速で100万台突破 前作より2倍以上速い (132
978: 赤点滅信号無視した車カスのSUVが軽自動車と出会い頭に衝突。軽がVの字に折れて19歳女性死亡 (125)
1015: Borderlands 3 -ボーダーランズ 3- part19 (124)
1001: 「息子が英会話塾に出掛けたまま帰ってこない」9歳行方不明男児遺体で発見される。 さいたま (123)
1002: 【モデル】キムタク次女・Koki,スラリ美脚ショット公開「圧巻スタイル」「足長すぎ」絶賛の声殺到★2 (12
992: サケ漁は先住民族アイヌの権利だ。!無許可漁で取り調べ1匹2匹3匹4匹5匹…たくさん捕獲する (123)
982: 【朝ドラ】「なつぞら」は最終回も近いのに、さっぱり盛り上がらないのはなぜ? ★2 (122)
996: 福島汚染水廃棄問題 韓国『日本人が飲め。日本の上水道に供給しろ。お前らの国土へ流せ』罵倒様々 (121)
1008: 【アズレン】アズールレーン Part4045 (120)
1153: 松山ティファニー 伊予鉄高島屋に出店へ 松山三越からは撤退か (116)
2: 【中央日報】「現代車、日本産部品在庫量拡大」…「ホワイト国」除外で韓日自動車業界が緊張[9/18] (113)
1170: 【千葉】ゴルフ練習場の倒壊ポール 1週間経っても撤去作業始まらず 市原市 ★9 (113)
988: 【野球】楽天 台湾・ラミゴを買収へ 有望若手多数の人気球団“パイプ”さらに強固に (110)
978: 【テレビ】モリマン、東京での芸人生活を振り返り「ルールもクソもねぇ。敵しかいなかった!」 (109)
1160: 【千葉県警】台風被災者に高額請求=「勝手に作業」相談相次ぐ (108)
975: 【高校野球】スクープ! U18永田裕治監督(前報徳学園)サイン盗み指示していた 最終の豪州戦、選手拒絶で未遂に
1008: 【サッカー】<ACL4強入りの浦和レッズ>リーグ戦低迷をサポーターに謝罪!「是が非でもJ1残留を果たす」 (
1164: 【パキスタン】スズキ・アルトがパキスタンでバカ売れ中 (100)
992: 【野球】鳥谷退団セレモニーを検討、真弓前例に30日開催へ (95)
1157: 詐欺の疑いで芦屋の税理士劉翔とマダムヤンを逮捕 (95)
1117: 【サウジ石油施設】攻撃はイラン南西部から来たと確信している、巡航ミサイルも使用=米高官 (93)
3: 中国→龍、韓国→虎、日本→? (92)
989: お前らは多脚戦車で何が好き?おれはブリザードガンナー。実用的な多脚戦車が開発される→動画 (91)
58:  ◆◆◆9月の市況 その10◆◆◆ (86)
1000: 【テニス】<大坂なおみ>元コーチに勝訴「獲得賞金の20%を永久に受け取る契約をした」として訴えられていた (
15: 【日本は抗議せず・・】韓国、輸出優遇ホワイト国から日本を除外へ (85)
998: 【片鱗】思えば山口真帆って最初からヤバかったよな (84)
98: 【USD/JPY】ドル円専用スレ Part29631【$\】 (83)
1015: 結婚のデメリットあるか? (82)
993: 11歳女児に乱暴した西野優輔容疑者、絶対に社会的に許さない。ネットタトゥーされろ (80)
976: 新型カローラとプリウスの見分けが付かない【車カス】 (77)
1009: 【芸能】山口真帆 24歳バースデーで4カ月ぶりにファンの前へ「たくさん心配かけた」 (76)
988: ドコモ、ファーウェイ5G端末の採用見送り「Androidを搭載できなくなるため」 (76)
1004: 【音楽】<岡崎体育>ジェットーコースターへの持論に共感の声「強要する人の方が怖い」 (75)
990: 【中日】松坂大輔の去就は「世論で決めるわけじゃない。球団の都合で決める」白井オーナーが言及 (72)
1263: ディアドラ、次走は凱旋門賞かチャンピオンズデー (72)
1138: 【研究】短時間睡眠でも健康に影響ない「ショートスリーパー」の遺伝子、米研究者が新たに発見 (72)
996: 【野球】阪神マルテあるぞ打率3割「まずは自分が楽しんで」100試合 .291 12本 49打点 (70)
977: 【芸能】中尾ミエ、ワタナベエンタ所属を発表 28年ぶりの“古巣”「私もまだいける!」 (70)
403: 生物が発生した理由は何なの? (68)
1122: 【今度はメキシコで!】南部の製油所が爆発 (68)
1011: 【芸能】熊田曜子の“手料理”に辛辣な声「馬のエサ」 (67)
1118: 【しっしっ煮だ】日韓改善、米国を頼るな=仲介機能に疑問−米専門家インタビュー (66)
1018: 【ロシア】「違法操業の北朝鮮漁船2隻拿捕…国境警備隊3人負傷」[9/18] (65)
1165: 【モロコシおかわりか】日米貿易協定、米国側は現協定が不十分とし金融サービスの自由化などを注文 (63)
990: 水にぬれやすいキャンバススニーカーは (62)
1: 【小林よしのり】左翼が韓国批判を封じようと躍起 「反日」は良くて「嫌韓」は悪い、では説得力がない (55)
1016: 育児している奥様(IDなし)1754 (55)
972: 【兵庫】( ^ν^)「風が強いから線香は車内で火をつけるかか…」→ (55)
1008: 【悲報】小泉進次郎、完全に鳩山由紀夫二世だった 何言ってるか理解不能で支離滅裂 wwwwwwwwww (55
1174: 【預けたら】マイナス金利拡大なら「口座維持手数料」を検討 メガバンク (55)
1013: 【中国】ソロモン諸島を評価=台湾断交「発展のチャンス」 (50)
60: 【速報】急騰・急落銘柄報告スレ12366 (49)
1014: 【韓国】「夫婦喧嘩de焚身」(城南)[09/18] (48)
1007: 【試される内地】 千葉県、停電のせいでマンホールのうんこ水が限界に、まもなく各ご家庭に逆流へ (47)
5: 【リスカブス】 「韓国は腹立ちまぎれに自害した」――米国から絶妙な指摘 (46)
986: 【芸能】SKE松井珠理奈 格闘技を見て感動もらった「素晴らしさ伝えたい」 (46)
1173: 【約束は守る!】#小泉進次郎環境相 、何言ってるかよく分からない(画像・動画あり)★4【具体策は?】 (45
1145: 自衛官 1万円盗みの疑いでちょうかい免職 (44)
1143: 【地域】人が集う場へ 鳥取大丸がリニューアルオープン (44)
1003: 【悲報】AKBINGO、リニューア説完全に無くなる (42)
1006: 【サッカー】<中島翔哉>監督に大目玉食らった理由。目撃者は語る「やばかった。めっちゃ怖かった」 ★2 (41
1274: 日本歴代最強牝馬はブエナビスタ (41)
1010: 博多ヲタだけど正直ホークスタウンに劇場出来るくらいなら新劇場いらない (41)
981: 千年周期の彗星が大気圏かすめて地球の同一地点を隕石爆撃するって科学知識ない馬鹿の思い付きだからな (40)
1167: 中部空港さん、アカウントの誕生日の欄に2005年と書き、こども認定されツイッター凍結される (40)
8: 【鉄道】八高線209系に開通85周年ヘッドマークつき列車、10/1〜11/30運転 (39)
1137: 【国際】南米エクアドル ハッカー攻撃でほぼ全国民の個人情報流出 (39)
5: 【中央日報】LGの攻撃にサムスン反論「モノクロテレビの時の基準を掲げるのか」[9/18] (38)
1004: 目をそらしたら殺されてしまうホラー映画『シライサン』ガラケーで撮影される『キモトサン』はまだか (36)
1121: 【千葉】断水の解消進むも停電で下水処理が動かず 多古町 (36)
1003: 【サッカー】<香川真司>所属のレアル・サラゴサ、集団感染で最新試合が異例の延期 (35)
1271: 実は違いがよく分かっていないもの (35)
400: 山本太郎「消費税増税とか血も涙もない千葉が苦しんでるのに増税か?政権交代しなきゃてかしちゃうよ」 (34)
1173: 【埼玉】さいたま・見沼区の集合住宅 遺体で発見された不明小4男児 首に絞められたような痕 (34)
398: 大日本帝国「特攻隊は家族を守るために死んだのではない!」 (32)
396: 公務員年収729万円、民間年収432万円。公務員報酬は民間準拠も大企業だけ調査対象で非正規社員除外 (32)
1016: これを真顔で言うからたまげる 「日本の韓国除外は違反だが、韓国の日本除外は規定に準拠している」 (32)
385: 9/18(水) おまいらおはようございます( ^ω^ ) (32)
1011: カネキン、筋トレのやりすぎで遂に身長が縮む・・ (32)
1008: 【画像】大阪>>>>>>>>>>>>日本国家 (32)
1148: 【安倍首相】千葉の停電復旧などに予備費13.2億円 台風15号被災者支援強化で首相方針 (31)
987: 【芸能】松田翔太 誕生日は妻と手繋ぎ…結婚から1年も守る夫婦の約束 (30)
1264: 【サートゥル因縁】川田がまた暴言!!「ルメを上から見下ろせるのが嬉しい』【ルメール激怒!!】 (30)
991: 【急募】滝川クリステルをカッコ良く改名してくれ (30)
1280: 性格が悪い人間が多そうな都道府県は? (29)
1009: K i s - M y - F t 2 の噂 Part2627 (28)
997: ジャップだぜ。奴隷魂。 (27)
995: お手柄ガス会社社員トリオ、連携プレイでひき逃げ被害者を救助&犯人捕まえる (27)
980: 9月22日は車カス禁止のカーフリーデー!市長が車乗り入れ禁止を呼びかけ。名古屋で自転車イベント (27)
992: 【朝まで徹底討論】NMB48梅山恋和はどうしてオワコンになってしまったのか?【横野すみれ】 (27)
1182: 【本番速報】小倉最大級のソープランドを摘発。売春の場所を提供した容疑。福岡県警 (26)
1002: 青葉容疑者危篤状態脱するも見えぬ逮捕。火傷治療の硝酸銀風呂でデッキブラシで背中を擦る日はいつか (25)
973: 青春コンプとかいう絶対に治らない病気 制服デートとかしてみたかったなあ…(´・ω・`) (25)
1276: ゼウス「糞食い民族が生意気にもギリシャ・アテネでやっていたオリンピックの猿真似するみたいだな」 (25)
983: フランコ政権はスペインじゃない!スペインさんゲルニカを爆撃したのはスペインとした解説に抗議 (24)
60: 日経225先物オプション実況スレ35524 (24)
406: 【悲報】IAEA総会で日本代表が韓国代表に一方的にやり込められる (23)
391: Σ(゚□゚;)!<ひゃだ!永久戦犯加害国の日本が韓国に怒るっておかしいわよ!!?? [櫻子学級] (23)
999: 沖縄県の玉城デニー知事、ようやく浦添市長と会談 5ヶ月も面談要請放置し批判殺到 (23)
1268: ハローワークっていい求人なくね? (23)
1116: 【FB仮想通貨】フェイスブックのリブラに類する通貨、許容できず=ショルツ独財務相 (23)
1010: 【ピムス】Pimm's 応援スレ (22)
1270: 携帯電話3キャリア会社、結局全然値下げされない (22)
1006: 井戸の底から少なくとも29人分の遺体が発見されるけどメキシコだしニュースにもならない。 (21)
984: 社民党の照屋寛徳衆院議員が引退へ 「沖縄独立」や「沖縄は公選法特区」発言の人 (21)
1: 【京郷新聞】『用日』...日本との再会[09/18] (21)
1009: 【悲報】ヒカキンさん、1965万円のトランクを買ってしまう wwwwwwwwww (21)
1010: PSO2今さらはじめるか迷う 186 (21)
1011: 【米GM工場】約5万人が大規模ストに突入 (21)
1139: 【鉄道】千駄ヶ谷駅の新駅舎供用開始は10/27 新ホームは来年3月下旬から (21)
1115: 【トランプ米大統領】イラン大統領との会談に前向きになれない (21)
1009: 大仁田厚(61)、愛人トラブル (20)
1004: 山口真帆事件で評価を落とさなかった指原莉乃のすごさ (20)
1265: 横山ルリカって写真の顔がいつも同じだよな (20)
1015: 刀剣乱舞-ONLINE-愚痴スレ 123辺り(ワッチョイIP有り) (20)
399: スーパーで買ってきた3足260円の靴下を遂に満を持しておろす時がやってきたのである (19)
395: ソーラーの次は風力! 軽量コンパクトなポータブル風力発電機が日本上陸 (19)
387: なんか右人差し指と左足親指の付け根が痛い (19)
1272: 平場のレースでもめっちゃドキドキする奴 (19)
390: ロシア、北朝鮮の密漁船を拿捕 警備隊員3人負傷 (18)
994: 田中美久の乳を、10秒間吸うか揉めるかどちらか1つ選べる権利があったらどっちにする? (18)
409: 粉末洗剤が売ってないでござる(´・ω・`) (17)
408: オール電化住宅はそういうことだ (17)
402: 勝手に屋根修理を行って25万円を請求、台風被害に便乗した悪質商法に注意喚起 (17)
1014: 【殺人パヨク革マル枝野幸男】立憲民主党・蓮舫、息子が出演の「ノーサイド・ゲーム」最終回を熱烈応援 (17)
1015: ===ヨコハマの奥様スレッド(IDなし)その12=== (17)
1012: 更年期障害に悩む奥様96 (17)
1179: 【転売ヤー】北海道日高町の牧場でウイニングチケット号のたてがみ切られる。メルカリに出品か (17)
1004: 中学の同窓会メチャクチャ行きたくないんだが (16)
994: 台風15号 政府初動対応に批判=内閣改造で「空白」 (^ν^消費税延期決断したら許してやろうず (211)
7: 【経団連】政府の就職氷河期対策、効果検証を…雇用保険の財政悪化警戒、安易な積立金の取り崩しにくぎをさす ★2 (1
979: 【音楽】スガシカオ『日光アレルギー』を告白 「キツかった」 (189)
1003: 「分譲マンション」って「一軒家の欠点」と「賃貸の欠点」しかなくね?どんな馬鹿が買ってるの? (188)
1007: 【FEH】ファイアーエムブレムヒーローズpart4937 (174)
1178: 【常識】新聞投稿「1円玉の悲しみ」が話題 おじいちゃん、75枚払い、店員に「営業妨害」といわれ立腹 (170
1149: 【消費税増税】元財務官僚 ?橋洋一氏「消費税引き上げは本当は必要ない」 (161)
1001: 【テレビ】<浜田雅功>次男が大学卒業! 高校はアメリカ…妻・小川菜摘が報告 (160)
1000: 日本人ってなんで韓国に憧れてしまうんだろうな?やはり「血」なのかねぇ (159)
999: 【女優】新木優子、恋人のような距離感にドキッ! セカンド写真集発売決定 水着ショットも (149)
976: 【音楽】岡田有希子さんアルバム10月発売 竹内まりや追想 (148)
19: 【ソウル新聞】『新聞記者』#望月衣塑子に注目・・・「日本メディアの象徴」[09/18] (145)
1166: 【米国】トランプ大統領、ボルトン氏後任にケロッグ氏らを検討 (145)
986: 白髭神社の鳥居を破壊。琵琶湖の水上バイカスどもの狼藉。神罰当たって苦しんで死ねカス馬鹿ボケカス (144)
985: 日本「EEZに北公船が不法侵犯、厳重な抗議」北朝鮮「EEZに海保巡視船が不法侵犯、厳重に抗議」 (144)
1126: 【東電からのお知らせ】千葉県の停電、27日までにおおむね復旧します (144)
985: 【サッカー】UEFA-CL第1節 南野が2アシスト!伊東との日本人対決制す!奥川も出場のザルツブルクが大勝 (
1125: 【スマホ】サムスン「ギャラクシーノート10」 韓国販売が最速で100万台突破 前作より2倍以上速い (132
978: 赤点滅信号無視した車カスのSUVが軽自動車と出会い頭に衝突。軽がVの字に折れて19歳女性死亡 (125)
1015: Borderlands 3 -ボーダーランズ 3- part19 (124)
1001: 「息子が英会話塾に出掛けたまま帰ってこない」9歳行方不明男児遺体で発見される。 さいたま (123)
1002: 【モデル】キムタク次女・Koki,スラリ美脚ショット公開「圧巻スタイル」「足長すぎ」絶賛の声殺到★2 (12
992: サケ漁は先住民族アイヌの権利だ。!無許可漁で取り調べ1匹2匹3匹4匹5匹…たくさん捕獲する (123)
982: 【朝ドラ】「なつぞら」は最終回も近いのに、さっぱり盛り上がらないのはなぜ? ★2 (122)
996: 福島汚染水廃棄問題 韓国『日本人が飲め。日本の上水道に供給しろ。お前らの国土へ流せ』罵倒様々 (121)
1008: 【アズレン】アズールレーン Part4045 (120)
1153: 松山ティファニー 伊予鉄高島屋に出店へ 松山三越からは撤退か (116)
2: 【中央日報】「現代車、日本産部品在庫量拡大」…「ホワイト国」除外で韓日自動車業界が緊張[9/18] (113)
1170: 【千葉】ゴルフ練習場の倒壊ポール 1週間経っても撤去作業始まらず 市原市 ★9 (113)
988: 【野球】楽天 台湾・ラミゴを買収へ 有望若手多数の人気球団“パイプ”さらに強固に (110)
978: 【テレビ】モリマン、東京での芸人生活を振り返り「ルールもクソもねぇ。敵しかいなかった!」 (109)
1160: 【千葉県警】台風被災者に高額請求=「勝手に作業」相談相次ぐ (108)
975: 【高校野球】スクープ! U18永田裕治監督(前報徳学園)サイン盗み指示していた 最終の豪州戦、選手拒絶で未遂に
1008: 【サッカー】<ACL4強入りの浦和レッズ>リーグ戦低迷をサポーターに謝罪!「是が非でもJ1残留を果たす」 (
1164: 【パキスタン】スズキ・アルトがパキスタンでバカ売れ中 (100)
992: 【野球】鳥谷退団セレモニーを検討、真弓前例に30日開催へ (95)
1157: 詐欺の疑いで芦屋の税理士劉翔とマダムヤンを逮捕 (95)
1117: 【サウジ石油施設】攻撃はイラン南西部から来たと確信している、巡航ミサイルも使用=米高官 (93)
3: 中国→龍、韓国→虎、日本→? (92)
989: お前らは多脚戦車で何が好き?おれはブリザードガンナー。実用的な多脚戦車が開発される→動画 (91)
58:  ◆◆◆9月の市況 その10◆◆◆ (86)
1000: 【テニス】<大坂なおみ>元コーチに勝訴「獲得賞金の20%を永久に受け取る契約をした」として訴えられていた (
15: 【日本は抗議せず・・】韓国、輸出優遇ホワイト国から日本を除外へ (85)
998: 【片鱗】思えば山口真帆って最初からヤバかったよな (84)
98: 【USD/JPY】ドル円専用スレ Part29631【$\】 (83)
1015: 結婚のデメリットあるか? (82)
993: 11歳女児に乱暴した西野優輔容疑者、絶対に社会的に許さない。ネットタトゥーされろ (80)
976: 新型カローラとプリウスの見分けが付かない【車カス】 (77)
1009: 【芸能】山口真帆 24歳バースデーで4カ月ぶりにファンの前へ「たくさん心配かけた」 (76)

19: OODB - オブジェクト指向データベース (305)

人気スレッド2




1002: 【MHW】導きの地総合 Lv-13【LEVEL DOWN...】 (982)
94: 【GBP】ポンドはどうする?part5734【£】 (953)
44: うたコン「熱唱!人生は歌とともに…」★5 (908)
8: 【社会】「日韓トンネルの連結で和解へ」米投資家ジム・ロジャーズ氏が視察[9/18] (892)
1066: 【赤羽国交相】「無電柱化」への対応全国で急ぐ…千葉停電の長期化受け ★3 (883)
1064: 【大分】〜受動喫煙をなくそう〜 コンビニ灰皿、一斉に撤去 受動喫煙対策で実験 ★3 (845)
43: サラメシ シーズン9「第17回」★2 (839)
965: 【悲報】eスポーツ大会優勝者の賞金が、500万円から10万円に減額されてしまう (824)
142: なんJVYouTuber部 4941 (817)
957: セブンイレブン、税込100円の商品を3個買うと合計301円になるシステム導入 (806)
943: 【身に染みてる】韓国「嫌い」、人生経験が増えるほど上がることが判明 朝日新聞世論調査 (754)
962: 【音楽】SASUKE「最近のJポップは、日本らしさが消えていて・・・」 (724)
1071: 【返討ち】自宅狙われた男性、覆面の十代3人を射殺 米ジョージア州 (719)
1009: 【モンスト】モンスターストライク脱・超初心者スレ 479【脱超】 (659)
94: 【USD/JPY】新ドル円15125【雑談禁コテ禁IP無 (654)
5: 【芸能】吉沢亮、高校時代は“カースト最下位”「リア充の悪口言ってた」 (644)
3: NGT48山口真帆さんが配信にて『殺されてたら…』 運営はメンバー関与を認めるも、被害者が謝罪★1403 (640
26: 【消費増税】セブン‐イレブン 計算方法変更で税込み300円が301円に (638)
1003: 【アズレン】アズールレーン Part4044 (635)
969: 【美容家】IKKO 1カ月の美容代は「350万円以上」 幹細胞点滴にレーザー (570)
1015: 【研究】死の直前に起きる「お迎え現象」「手鏡現象」は妄想か本物か 何度も目の当たりにした人がいる ★2 (5
47: プロフェッショナル 仕事の流儀「外国人労働者に何が?支援の第一人者に密着」★2 (554)
973: 【芸能】ぶっちゃけこんなに売れると思わなかった男性有名人ランキング 2位はHIKAKIN 3位にピコ太郎 (
1029: 【千葉】台風9日目でも「助けて…」ツイッターにSOS投稿 (538)
10: 左翼が韓国批判を封じようと躍起 「反日」は良くて「嫌韓」は悪い、では説得力がない (502)
1013: 艦これ愚痴スレ Part1884 (464)
48: [再]ブラタモリ「阿寒・摩周〜“色”とりどりな宝の秘密とは!?〜」 (462)
1019: 【AERA】元朝日新聞記者「夏でも電気なしで無問題!」 (462)
948: 【速報】 山本彩の新曲、小林武史がプロデュース!←誰だよ? (442)
17: 【国際】韓国、日本を輸出優遇国から除外 (427)
9: 【毎日新聞】日本では韓国文学が静かなブームになっている[9/17] (420)
951: 【野球】養育費不払い、賭け麻雀……元近鉄・石井浩郎氏のあきれた議員生活 (414)
1077: 【社会科学】囚人のジレンマの最適解はやり返すよりも逃げるが勝ち? - 立正大らが分析 (410)
19: 【画像】 元NGT48山口真帆さん、太る (375)
941: 【テレビ】<青木理>台風被害の千葉の復旧が遅れ「内閣改造をしている場合だったんだろうか」 (372)
1065: 【ヤマト発進!】安倍首相「宇宙作戦隊を創設する。航空宇宙自衛隊への進化も、もはや夢物語ではない」★2 (37
49: [再]ドラマ10 これは経費で落ちません!(8)「嘘つきとノベルティの巻」 ★2 (357)
45: クローズアップ現代+「【対談】是枝裕和×ケン・ローチ新作秘話家族と社会を語る」 (357)
937: 【速報】山本彩重大発表キタ━━ヾ(゚∀゚)ノ━━!! (356)
1011: 【シャニマス】アイドルマスター シャイニーカラーズ 802週目【enza】 (356)
946: 【ラグビー】「時が来た」ワールドラグビー会長W杯の成功に自信 (337)
945: AKB48×SHOWROOM ★1605 (324)
14: 【毎日新聞】「K-POPは世界を一つにできる」[9/17] (321)
3: 【GBP】ポンドはどうする?part5735【£】 (318)
987: 【朝日新聞】嫌韓をあおるようなメディアの風潮は、いかがなものか[9/17] (307)
960: 【アーティスト】山本彩が小林武史プロデュースのニューシングル発表!12月にはフルアルバムも (306)
1009: 【DMM】グランブルーファンタジー【転載禁止】 part1380 (306)
912: 歴代48グループメンバーの「各都道府県出身の代表」を選ぶなら? (301)
951: 朝日世論調査「次の自民党総裁にふさわしい人は?」 1位小泉、2位はマスコミと野党だけに人気の石破 (298)
956: 【音楽】石橋貴明、野猿メンバーと新ユニット「B Pressure」結成を発表★2 (290)
959: 【芸能】「ソフト麺見たことない」鈴木福が語る最近の給食事情 さんまツッコミ「カフェやないか!」 (286)
11: 【福島汚染水】東京電力「トリチウム水海洋放出問題」は何がまずいのか? その論点を整理する (282)
940: 【画像】 26歳無職に待ち伏せわいせつされた地下アイドルがカワイイと話題wwwwwwwwww (278)
964: 【上級国民】京アニ放火容疑者、呼吸器付け会話不能で逮捕めど立たず見送りへ (271)
61: 今夜はナゾトレ★2 (268)
1088: 【難民】キリスト教改宗のイラン人男性 「難民認定却下は違法」東京地裁 (263)
932: 【悲報】シーチキン値上げ (260)
934: 名古屋市、観光対策で名古屋駅周辺にアニメロード整備へ (255)
968: 北海道に行ってびっくりしたこと。 (254)
1028: 【徳島】「彼女が欲しかった」はがき盗み見て、郵便法違反でアルバイトの男(55)逮捕 (252)
1006: 【春場ねぎ】五等分の花嫁 ネタバレスレ143等分目 (249)
962: 【カッケー】AMラジオのみ、5MT、フェンダーミラー、ドアはぐるぐる回すY31型セドリックパトカーが引退 (2
936: クズ主人「これ昨日のカレーじゃね」あたし妻「うん。捨てれば良かったの?」 ・ (247)
939: LGディスプレイ、フッ化水素を「今月中に100%国産化」 なおフォトレジストとフッ化ポリイミドは無理 (242
913: 【特大悲報】うたコンに珠理奈ちゃんがいないんだが!!!WWWWWWW (242)
29: 【アニラジ専門】超!A&G+14173 (239)
953: B93W62H90、グラビア界最高峰ボディのグラビアアイドル (236)
16: 【韓国】 中国に旭日旗問題を説明したら支持された。日本が戦犯国であることを公論化するチャンスだ[09/17] (
997: 【ミリシタ】アイドルマスターミリオンライブ! シアターデイズ Part2561 (225)
982: 【本スレ】SKE48★17860【本スレ】 (224)
1201: こいつが出てるとチャンネル変える芸能人・有名人 (208)
1084: 【エプスタイン事件】少女虐待容疑の米富豪のMIT寄付、理事長が容認 大学ぐるみで匿名化 ★2 (205)
1040: 【宇宙】また太陽系の外から?急接近する奇妙な彗星を発見 2017年のオウムアムア以来 (205)
1074: 【サメいじめ!】サメがボートに引き回され死ぬ、動画の男らに禁錮刑 サメが苦しむ姿を見て笑う 米 (204)
970: 【海外】ブラッド・ピット、いまの憧れはデヴィッド・ボウイ (201)
1006: 【Switch】大乱闘スマッシュブラザーズ SPECIAL 1036スレ目 【スマブラSP】 (199)
955: 【芸能】仲里依紗、30歳目前の美しい腹筋を披露「自己満写真とりました」 (196)
970: 山口探偵団スレがいまだに地下で勢いトップ・・・ (196)
961: パチンコに負けむしゃくしゃしたのでJK(15)をレイプ→未遂で逮捕 (179)
966: 【芸能】小雪の実姉、弥生が44歳で第1子出産「無事に産まれてきてくれてありがとう」 (178)
10: 【しんぶん赤旗】日本の国内世論が韓国を「敵視」する風潮を強めていることは問題[9/18] (176)
23: 【女性自身】ミヤネ屋出演の元韓国大使 解説内容が「デマ」と批判殺到[9/17] (175)
1058: 【EEZ煮だ】北朝鮮「われわれの経済水域に日本の巡視船が侵入」と主張 (174)
959: 【速報】燃やされて25億以上寄付を受けた京アニさんがつくった世界に誇れるアニメがこれ (170)
966: ぶっちゃけオマンコって、なんとも言えない塩味と酸味があるよね あの味で刺し身を食べれば多分美味い (168)
941: 北朝鮮に続き韓国でも「アフリカ豚コレラ」確認 致死率ほぼ100% ワクチンや治療法なし 日本のとは別物 (16
929: 『 性 格 悪 い 人 間 が 多 そ う な 都 道 府 県 と 言 え ば ? 』 ※1人一票守ること (
1073: 【京都】最古級の前方後円墳に石室、向日で出土 邪馬台国の女王、卑弥呼の墓説ある箸墓古墳に酷似 (165)
947: ヤクザはヤクザ罪で全員一致死刑にすべき。ヤクザの3親等もヤクザ因子もってるから全員死刑で。 (160)
1014: かんぱに☆ガールズ 5412社目 (159)
933: 地下アイドルの熱狂的ファンの男、自宅で待ち伏せしてわいせつ行為で逮捕 (158)
1009: 雑談独り言 ワッチョイ 9月17日 (154)
1012: まちカドまぞく 23丁目 (153)
901: 女の子に抱いていた幻想と現実が違ったっていうエピソードある? (153)
946: 荻野さん「ストレスは・・・ありますね」 → 非難殺到 (150)
1025: 【公共放送】NHK情報番組「あさイチ」でねつ造報道 石垣市議会が抗議 広報局「真摯に対応する」 (150)
1032: 【奈良】修学旅行の小遣い用現金33万円 盗んだ疑いで奈良市立富雄北小学校の教諭 25歳教諭逮捕 (149)
985: 【落ち目】AKBINGOがもう終わるんだけど何か言いたい事とかある? (147)
1254: 種付け52頭でオルフェ基地が各地で発狂中wwwwwwwww (146)
1009: 【社会】「無電柱化」への対応全国で急ぐ 停電の長期化受け 国交相 (145)
1238: 新潟千直走らせたら歴代日本最強馬って誰だと思う? (142)
969: 巨乳の魅力 (140)
6: ボックス、総流し、穴馬の複勝←この買い方する奴らって下手だよな (137)
1002: 【話題】N国・丸山穂高、東国原に反撃「竹島は『そのまんま』でいいんでしょうかね?」[9/17] (136)
957: NMB「母校へ帰れ」、結局STU「大好きな人」の売上に追いつかず敗北決定。 (135)
997: 【NO JAPAN】韓国で日本産ビールの輸入、97%減[9/17] (133)
944: 日本語ラップの始祖こと吉幾三が令和に放つ新しい方言ラップはこれだ! (130)
950: トラフ地震がくる 鳥の様子がおかしい 神奈川県 (126)
1014: 手品先輩 (125)
937: おい福岡県民説明しろ。「放生会」で泥酔した女が他人の車に勝手に乗り込み殴り逮捕「鬼ごっこしてた」 (120)
1015: 【百科事典】ウィキペディア第2152刷【Wikipedia】 (120)
1086: 【神奈川】40代男性がはしかに感染 横浜 (119)
935: 松井大阪市長『汚染水問題は全国で協力すべき。大阪もモチロン協力する』 小泉進次郎『俺は関係ない』 (116)
1208: RPGのバトル曲で一番好きなのは (115)
7: 京都大賞典のメンバーが凄い! (115)
95: 【NY原油】凄い勢いでいろいろ書くスレ$705【WTI】 (113)
940: 【芸能】<木下優樹菜>体調不良で7キロ減を報告!ファン「体調大丈夫ですか? よっぽどだったんですね」 (112
1007: 【PSO2】PHANTASY STAR ONLINE2【29685】 (108)
24: 【サウジ空爆】「イランが中東揺るがしている」=NATO事務総長 (108)
1007: 【ソ連】チェルノブイリの悲劇から30年経てなお続く危険な状況:画像あり (108)
999: 【韓国】韓国航空会社、ウォン安と原油価格の高騰が直撃 「ボイコットジャパン」も追い打ちに[9/17] (106
994: 【茂木外相】「韓国は科学的根拠に基づく主張を」福島の汚染水処理で[9/17] (104)
971: 子供の頃、日曜の晩に見てたテレビ番組wwww (100)
936: 【画像】 谷原章介を誘惑する矢作萌夏17歳さん、可愛すぎると話題wwwwwwwwwwwwww (100)
917: 甲斐心愛って何で急にメス化したの?wwwwwwwwwwwwww (100)
1024: 【都内上位大学の夏休みランキング】東大農→93日 東京外大→74日 東京理科大→34日 なぜなのか (100
942: 【ラグビー】<W杯訪日客向けに呼びかけ>「お願い、逮捕されないで」 (99)
1106: 【欧州各国で極右が躍進】1930年代の教訓は生きているか (98)
908: 【乃木坂】坂道研修生総合スレ★3【欅坂日向坂】 (97)
138: なんJAZLN部★156 (97)
1022: 【truelove】 真の愛は本当に存在するのか:オキシトシンを放出しているだけじゃないのか (96)
1007: ワンピース専用ネタバレスレッド Part4244 (93)
1010: 【大都】Re:ゼロから始める異世界生活【死に戻り127回目】 (93)
970: 【8万いいね】 ツイ民 「上司にするなら日本人よりも中国人」 (92)
1070: 【BBCも注目!】「先を急ぐ若者」#小泉進次郎 氏 日本政界を駆け上がる (92)
928: 【求刑11年から3年減】目黒女児虐待死の母親に執行猶予ナシ懲役8年判決、弁護側控訴の構えへ 東京地裁 (91)
60: 【潜在】 宮司愛海専用 2019/09/17(火) 【能力】 (90)
1010: 牛の生レバー提供疑い 会社役員逮捕・山形 (90)
1014: 【Uniqlo U】ユニクロU part127 (88)
1010: けものフレンズ【2】518人目 (88)
20: ロシア当局が北朝鮮の密漁船を拿捕し20人以上を拘束 「漁船」の武力抵抗で3人負傷 (88)
927: イコラブの大谷が飲酒 (88)
925: 『 S A 』 ←何を連想した? (88)
1007: 【SAGI】【豚叩き】ぷよぷよ!!クエスト 1152【ぷよクエ】 (88)
967: 高知県に行ってびっくりしたこと。★2 (87)
952: 【野球】退団も視野に進路を模索するT―岡田 オリックスで同情の声 (87)
973: 【急募】おぎゆかの水虫の治し方 (87)
953: 【野球】BC富山、二岡監督が今季限りで退任 わずか1年で「短い期間でしたが…」 (85)
1010: 【クレカ】「20%還元」の衝撃再び、JCBが過去最大キャンペーンを仕掛ける狙い (85)
3: 政府筋、「韓国」呼称を「南朝鮮」に変更する方向で調整か 国際標準の「South Korea」に合わせ (84)
953: 【瀬戸内】STU48★297航海目【本スレ】 (84)
938: 明日の猫舌SHOWROOMに賀喜遥香と金川紗耶が登場!YACはなし! (83)
1004: eスポ大会の賞金500万円がライセンス非所持で10万円に減額されてしまう (83)
934: AKB48新センター矢作萌夏ちゃんがお茶の間に見つかる!【NHKうたコン・サステナブル】 (83)
919: 大盛真歩ぴょんセンターのサステナブルキタ━━━━━━━━━━━(゚∀゚)━━━━━━━━━━━!!!!!!!!
1013: スーパービンゴギャラクシー 1 (83)
1037: 【千葉停電】電力大手の復旧応援7000人超 (83)
1: 【MHW】スラッシュアックススレ 変形61回目 (79)
942: 100歳のクソジジイ、車を運転し人をはねる。 (79)
898: 【指原】マンチ・カン太郎&ミヌエット五郎応援スレ★50【猫ーズ】 (79)
944: ◆芸スポ+スレッド作成依頼スレ★1180 (78)
909: 上西怜って可愛いのか? (78)
1078: 【ヨルダン派遣の爆弾探知犬】不適切な扱いで相次ぎ衰弱死 米国務省調査 (78)
1015: イエス】 これはわたしの愛する子 Part107 【キリスト】 (78)
938: 名無し雑談20190917〜 (77)
1010: 男子マラソン・長距離総合スレ Part273 (75)
969: 【美容家】IKKO 1カ月の美容代は「350万円以上」 幹細胞点滴にレーザー (570)
1015: 【研究】死の直前に起きる「お迎え現象」「手鏡現象」は妄想か本物か 何度も目の当たりにした人がいる ★2 (5
47: プロフェッショナル 仕事の流儀「外国人労働者に何が?支援の第一人者に密着」★2 (554)
973: 【芸能】ぶっちゃけこんなに売れると思わなかった男性有名人ランキング 2位はHIKAKIN 3位にピコ太郎 (
1029: 【千葉】台風9日目でも「助けて…」ツイッターにSOS投稿 (538)
10: 左翼が韓国批判を封じようと躍起 「反日」は良くて「嫌韓」は悪い、では説得力がない (502)
1013: 艦これ愚痴スレ Part1884 (464)
48: [再]ブラタモリ「阿寒・摩周〜“色”とりどりな宝の秘密とは!?〜」 (462)
1019: 【AERA】元朝日新聞記者「夏でも電気なしで無問題!」 (462)
948: 【速報】 山本彩の新曲、小林武史がプロデュース!←誰だよ? (442)
17: 【国際】韓国、日本を輸出優遇国から除外 (427)
9: 【毎日新聞】日本では韓国文学が静かなブームになっている[9/17] (420)
951: 【野球】養育費不払い、賭け麻雀……元近鉄・石井浩郎氏のあきれた議員生活 (414)
1077: 【社会科学】囚人のジレンマの最適解はやり返すよりも逃げるが勝ち? - 立正大らが分析 (410)
19: 【画像】 元NGT48山口真帆さん、太る (375)
941: 【テレビ】<青木理>台風被害の千葉の復旧が遅れ「内閣改造をしている場合だったんだろうか」 (372)
1065: 【ヤマト発進!】安倍首相「宇宙作戦隊を創設する。航空宇宙自衛隊への進化も、もはや夢物語ではない」★2 (37
49: [再]ドラマ10 これは経費で落ちません!(8)「嘘つきとノベルティの巻」 ★2 (357)
45: クローズアップ現代+「【対談】是枝裕和×ケン・ローチ新作秘話家族と社会を語る」 (357)
937: 【速報】山本彩重大発表キタ━━ヾ(゚∀゚)ノ━━!! (356)
1011: 【シャニマス】アイドルマスター シャイニーカラーズ 802週目【enza】 (356)
946: 【ラグビー】「時が来た」ワールドラグビー会長W杯の成功に自信 (337)
945: AKB48×SHOWROOM ★1605 (324)
14: 【毎日新聞】「K-POPは世界を一つにできる」[9/17] (321)
3: 【GBP】ポンドはどうする?part5735【£】 (318)
987: 【朝日新聞】嫌韓をあおるようなメディアの風潮は、いかがなものか[9/17] (307)
960: 【アーティスト】山本彩が小林武史プロデュースのニューシングル発表!12月にはフルアルバムも (306)
1009: 【DMM】グランブルーファンタジー【転載禁止】 part1380 (306)
912: 歴代48グループメンバーの「各都道府県出身の代表」を選ぶなら? (301)
951: 朝日世論調査「次の自民党総裁にふさわしい人は?」 1位小泉、2位はマスコミと野党だけに人気の石破 (298)
956: 【音楽】石橋貴明、野猿メンバーと新ユニット「B Pressure」結成を発表★2 (290)
959: 【芸能】「ソフト麺見たことない」鈴木福が語る最近の給食事情 さんまツッコミ「カフェやないか!」 (286)
11: 【福島汚染水】東京電力「トリチウム水海洋放出問題」は何がまずいのか? その論点を整理する (282)
940: 【画像】 26歳無職に待ち伏せわいせつされた地下アイドルがカワイイと話題wwwwwwwwww (278)
964: 【上級国民】京アニ放火容疑者、呼吸器付け会話不能で逮捕めど立たず見送りへ (271)
61: 今夜はナゾトレ★2 (268)
1088: 【難民】キリスト教改宗のイラン人男性 「難民認定却下は違法」東京地裁 (263)
932: 【悲報】シーチキン値上げ (260)
934: 名古屋市、観光対策で名古屋駅周辺にアニメロード整備へ (255)
968: 北海道に行ってびっくりしたこと。 (254)
1028: 【徳島】「彼女が欲しかった」はがき盗み見て、郵便法違反でアルバイトの男(55)逮捕 (252)
1006: 【春場ねぎ】五等分の花嫁 ネタバレスレ143等分目 (249)
962: 【カッケー】AMラジオのみ、5MT、フェンダーミラー、ドアはぐるぐる回すY31型セドリックパトカーが引退 (2
936: クズ主人「これ昨日のカレーじゃね」あたし妻「うん。捨てれば良かったの?」 ・ (247)
939: LGディスプレイ、フッ化水素を「今月中に100%国産化」 なおフォトレジストとフッ化ポリイミドは無理 (242
913: 【特大悲報】うたコンに珠理奈ちゃんがいないんだが!!!WWWWWWW (242)
29: 【アニラジ専門】超!A&G+14173 (239)
953: B93W62H90、グラビア界最高峰ボディのグラビアアイドル (236)
16: 【韓国】 中国に旭日旗問題を説明したら支持された。日本が戦犯国であることを公論化するチャンスだ[09/17] (

上位板 人気

97: システム構築ベンダの実力 (944)
221: Oracle 質問総合スレ13 (901)
159: 【9i】オラクルマスターGOLDのスレ【10g】 (897)
52: MySQL vs PostgreSQL Part2 (889)
177: 彼女にINSERT権限がありません (825)
26: SQLite Part.10 (804)
64: Firebird関連スレ3 (688)
38: PostgreSQL Part.11 (678)
109: 【無料DB】OpenOffice2.0?Base【Accessイラネ】 (646)
29: はじまりです。 (588)
92: MySQL 5.0 (558)
63: 何故データベース設計は軽視されるのか? (539)
155: 【より良い】データモデリング【モデルを】 (534)
54: IBM DB2 総合スレ2 (529)
96: デフォルト名無しネームを決めるスレ (502)
215: DB設計を語るスレ 10 (451)
80: ☆ 世界最速のデータベース SAS ☆ (449)
56: DB板のみんなでUDやるぞ! (417)
30: XML統合スレッド (402)
134: ADO.NETの質問・雑談スレ2 (401)
192: Oracle? DB2? Symfoware? HiRDB? SQL鯖? (397)
189: 【富士通】Symfoware【ティムポウェア】 (395)
83: OTN掲示板を生暖かく見つめるスレ (391)
160: ADO DAO など接続方法について (363)
167: 成績管理システムを作ろう!2【社会貢献】 (357)
182: MSDEよりいいDB、ありませんか? (347)
183: 諸君、私はSybaseが大好きだ【ASE】 (346)
81: オラクルマスターsilverの資格試験について (316)
61: DBのデータ検証&便利ツールはどんなのをお使い? (307)
19: OODB - オブジェクト指向データベース (305)
43: データベースプログラミングに最適な言語は何か (302)
212: 【Pure】HSQL database engine【Java】 (298)
21: 頼むから正規化しろよ 第二正規形 (290)
66: ハロワの職業訓練でデータベースやってるんですが。 (288)
146: オラクルマスターの給与 (283)
227: 自治スレ@DB板 2 (278)
62: MariaDB (277)
58: 【M言語】キャシエ・CACHE【MUMPS】 (275)
94: CSVファイルのスレ (272)
226: UNIX DBMはこちら(GNU gdbm, Berkeley DB etc...) (259)
3: Oracle>>>>>>SQLServer (257)
100: 【オラクル>ポストグレスの理由】⇒言い訳の為 (254)
157: WebObjectsってどうなん。 (246)
5: MySQL 総合 Part26 (239)
178: フィールド名は日本語にするか、英語にするか (230)
18: DBってドラゴンボールの略だよね? (229)
203: dbMAGICを超えるDBMSは未来永劫現れない。 (228)
42: 【Java】H2 Database Engine【GCJ】 (217)
138: 数十メガバイトのファイルをどんどん格納できるDB (207)
233: 【安易ダサすぎ】データベース→DB→ドラゴンボール (205)
88: データベース雑誌・書籍 (204)
71: データベース関連資格スレ (198)
37: 【ダッチ製】 Servoy のスレ Table01【大丈夫?】 (198)
130: 推薦図書/推薦HP/必読書のためのスレッド (188)
131: ストアドよりインデックスのほうが速いよ (183)
231: データベースなんか作れるかよ! (173)
137: SELECT * に続けて何か書け! (172)
104: 【DBMS】 HiRDB (168)
147: 【10g】オラクルマスター Silver Part3【11g】 (164)
149: データベース系の仕事をしたくて探しているのですが (164)
49: 【オンメモリ%メモリデータベース【インメモリ】 (163)
107: Oracleの30日間トライアル版について (159)
103: オブジェクトデータベース LINQ, DLinq のスレ (158)
95: ( ´_ゝ`)流石だよな俺らin DB板(´く_`  ) (156)
228: [終了]今は亡きInformixに文句を言うスレ[おつかれ] (153)
145: データベース破壊録カイジ (153)
89: 不正アクセス犯がいます、警察に通報してください! (153)
201: mysqlについて語ろう (152)
40: いまの気持ちをSQLで表すスレ (152)
143: まじめにデータベースについて語るスレ (151)
46: SQLについて語るスレ (151)
206: さて、この板の看板だが (150)
108: 【KVS】 Key-Value Storeを勉強するスレ (148)
129: DB専用機はなぜでない (144)
180: 【PostgreSQL CE認定試験】ってどう? (139)
20:    D       B         (139)
213: 個人情報保護法、どうする? (139)
41: DBを「でーびー」って言う人 (139)
127: MQ板もつくれ (137)
168: 【PureJava】 Derby 1 【OpenSource】 (135)
4: RDBMS比較総合スレ 【サーバ】 (134)
163: データベース技術を勉強したいのですが… (134)
126:   D  A  O  v s  A  D  O   (133)
50: (^^)BTRIEVE(^^) (131)
205: ここはデータベース板です (129)
59: DBのキャラ、ここが好きだ! (129)
13: ♪つっかもうぜ!DB! (126)
172: 年金情報DBの構成を公開しろ (125)
125: HiRDB vs Symfoware 国内最強RDBMSはどっち? (120)
251: Microsoft SQL Server 総合スレ 12 (116)
8: 【フラッピー】db-SOFTについて語るスレ【ホタル】 (114)
230: 制約っていらなくね? (114)
135: データベースって何ですか? (111)
39: MongoDB 1 (110)
101: 性別フィールドをSEXと定義するのやめて! (110)
166: 【Oracle】DB天下一武道会【MS-SQL】 (109)
148: PL/SQLできない香具師が上級SE (108)
208: 【】 MySQLを買収したSunを買収したOracleを 【】 (107)
229: 【レア技術者】 ORACLE DEVELOPER R6i 【狂え!】 (107)
69: プライマリーキーはchar型かそれとも数値型か (107)
78: 【SQL Server】 を SQL と略している奴 (106)
140: データベースエンジニア向け資格の市場価値 (104)
98: ニュース速報 in データベース板 (103)
133: Perlでデーターベースを扱う (102)
121: データベースを略してデーベーと呼ぶスレ (102)
73: 不正アクセス犯がいます!警察に通報してください! (102)
124: うっかり付けてしまった恥ずかしい表領域名 (98)
164: 今時Oracleを使ってない企業は貧乏人(w   (97)
123: 板=コミュニティ (96)
122: 日本語リレーショナルデータベース「五郎9」 (95)
47: つかDB技術者ってレヴェル低 (92)
169: 大至急!表を切り捨ててしまった (90)
120: ORACLEの一風変わった使い方の事例 (88)
36: データウェアハウス作ってる人いませんか? (88)
87: 先生!DB板らしいです! (85)
68: 映画マトリックスにおけるデータベースシステム (84)
153: DB板雑談スレ (82)
136: SQL Serverが1本8,800円(当社比:約90%値下げ) (81)
93: 静岡のヘンタイチンパンジー! (80)
106: 未来から来たけど、質問ある? (77)
118: ☆ドラゴンボールで論理演算について語る (76)
179: Oracleがベンチマーク結果を隠したがる理由 (74)
105: データベースを作ってみたいです (74)
209: T字形ER(TM)ってどうよ? (72)
199: 自分が立てた(構築した)DBを自慢するすれ (71)
33: だれかみずほ銀行のDBを直してやれよ (71)
119: いざ集まらん情報社会へ (70)
139: テクニカルエンジニア【データベース国家試験】 (70)
173: The Apache DB Project (Torque) (69)
198: SQL総合案内スレッド (68)
154: [大文字/小文字]SQLの正しい書式[改行/インデント] (68)
232: ○○のデータベースは板違い (67)
110: 「ビジネス」BIツール「インテリジェンス」 (66)
117: ■Flashとデータベースの連携についてのスレッド (65)
151: Oracle 儲かって儲かって、うはうは (65)
35: 新しい板の名前を決めるスレ (64)
204: SVC CHAOS (63)
188: 【SキュL Server】データベース 【(゚∀゚ )】 (60)
34: この板が生き残るために (59)
102: 【祝】 データベース板 【誕生】 (58)
152: スキャナで取り込んだ画像をすぐにデータ化 (57)
74: インデックスはどこに貼るべきか? (56)
115: なぜUNIX板とLinux板の間なのか? (53)
211: SQLの教材化に関する研究 (52)
79: 会社名募集 (52)
114: oracleの信憑性について (51)
113: ■データベース板スレッドガイド■ (50)
200: 2007年4月時点での Oracle vs MYSQL vs PostgreSQL (50)
184: DB技術の限界を超える新発想の高速検索技術ISSEI (49)
193: オラクルがソースで1980エソ (47)
116: 簑系ってどうよ (46)
158: 一番ボッタクリなDBってなに? (46)
150: 【マイナー】KANA Foundation【何それ?】 (45)
161: 姉歯DB設計 (45)
16: オラクルマスターシルバー (43)
53: オラクルさん・・・ (43)
262: 物質の速度が波動の光速を超えられない理由について (11)


 

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

人気スレ 上位板 ブックマ-ク見る