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

101
(1): [age] 04/07/25 10:40 ID:??? AAS
>>100
> 3)業務に変更があった場合、修正箇所を最小限にする。
>   なおかつその修正によって他の場所の修正が必要にならないようにする。 オブジェクト指向だな。

それはプログラミングの場合は確立されてるけど、過去のプログラムの実行結
果を格納しているDBの場合はどんな考察になるんでしょう?というのがここ
で展開してた議論だと思います。
102
(1): 04/07/25 21:40 ID:??? AAS
>>101
> 過去のプログラムの実行結
> 果を格納しているDBの場合はどんな考察になるんでしょう?というのがここ
> で展開してた議論だと思います。

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

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

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

#現実的にはRDBしか選択肢がないに等しいんだけどね。
103
(1): [age] 04/07/25 23:45 ID:??? AAS
>>102
>  そうだっけ? 別にRDBからOODBに移行する話じゃなかったと思うんですが。

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

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

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

上手い例えになるのか分からないけど、HTTPとかTCP/IPなんかは別にプログラ
ミングが便利になるために生まれてきたものじゃないです。
省5
104
(1): [age] 04/07/26 14:10 ID:??? AAS
>>95
>  研究者の方ですか?
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。

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

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

>  えーっと、無理です。きっぱり無理です。遅くとも10年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。
省29
105: [age] 04/07/26 14:24 ID:??? AAS
>>96
>  だからそんな複雑な事をしなくても、オブジェクトをそのままの形で格納できれば便利だと思いません?

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

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

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

> すいません。MDAって何ですか?
省11
106
(1): 04/07/26 20:16 ID:??? AAS
>>103
>それに対して「別にDBは言語の便宜のために生まれたものじゃないし、使う
>ものじゃない」というのが私の主張です。

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

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

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

>企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理
省10
107
(1): 04/07/26 20:31 ID:??? AAS
>相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか

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

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

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

>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。
省18
108
(1): U ◆CZtFsGiu0c 04/07/26 21:08 ID:??? AAS
なんか盛り上がってますね。現役のObjectStore使いです。
使った経験からいくつかコメントを。ただしOODB一般ではなく、あくまで
ObjectStoreに特化した話です。
>>88
>確かにその通りなんですが、じゃあOODBに適したソリューションはどんなもの
なのかのイメージがつかめません。

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

>>90
>速度が致命的なため、OODBとしての市場ってんですかね、分野ってんですかね、そういうものがこけたという話を聞きました。
省15
109
(1): 04/07/27 00:40 ID:f4b3F8Gz(1/2) AAS
非常に面白いスレですね。OODB未経験ですが割り込ませてください。
(U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。)

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

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

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

それこそWindowsでインストーラ一発でセットアップができて、パラメータチューニングが極力不要で、メンテナンスフリーで、
先に挙げたようなツールがGUIで提供されていて、それでいて当然日本語フル対応(←これ重要!2バイト対応されていない製品はユーザに嫌われる)
といったようなものがサクっと出てくるようでないと・・・。
(フリーのOODBもけっこうあるみたいですが、ここらへんを満たすものが果たしていくつあるのか・・・?)
111: U ◆CZtFsGiu0c 04/07/27 12:35 ID:??? AAS
>>109
>(U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。)

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

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

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

>あと個人的な意見ですが、OODB(やXMLDB)がなかなか流行らないのは、OODBに興味を持った人が簡単に試すことのできる製品が少ないからかもしれません。
省2
112
(1): [age] 04/07/27 16:04 ID:??? AAS
>>106
>  DBと言語と開発手法は完全に別々に進化の道をたどっているのでしょうか?
> それとも相互に影響を与えながら進化していっているのでしょうか?

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

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

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

> 人間が対処しなくてはいけないのは、人間ならではの頭脳、つまり判断を伴うところです。
省16
113
(4): [age] 04/07/27 16:41 ID:??? AAS
>>107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。

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

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

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

>  これはOODBの場合って話ですか? なぜでしょう?
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
省29
114
(1): [age] 04/07/27 16:54 ID:??? AAS
>>108
> OODBがよく使われているのは、CAD/CAMと通信系だと聞いています。

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

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

買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
省9
115
(2): U ◆CZtFsGiu0c 04/07/27 19:23 ID:??? AAS
>>113
>1:DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。

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

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

これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
省22
116
(1): [age] 04/07/27 19:56 ID:??? AAS
>>115
> できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
> 高いと思います。

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

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

> 一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
> 一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
省15
117
(1): 04/07/28 22:13 ID:??? AAS
>>112

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

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

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

> 「確認」も人間がやらなくちゃいけません。どのぐらい自動化するかは技術的可
省5
118
(2): 04/07/28 22:19 ID:??? AAS
>>113

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

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

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

組込型言語とでもいうんですかね。忘れました。
開発者が開発するソースは *.ec だったり *.pc だったりするんですが、一度普通のCのソース (*.c) に変換され、
それからコンパイルされ、普通の実行形式のプログラムに変換されます。
119
(1): U ◆CZtFsGiu0c 04/07/29 12:25 ID:??? AAS
>>116
>個人的にはXMLはストックするフォーマットというよりも、フローとか仲介用
のフォーマットだと思うので、オンラインにアクセスさせるのはまだ不安です。

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

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

そうとも限りません。設計作業を共同でやっているときにお互いの更新内容を
即時に反映させる、といったイメージです。通信系なら、各通信ノードが自分の
状態を書き換えると、即座に他のノードもしくは管理システムに通知される、
という仕組みに使われているはずです。
省11
120: U ◆CZtFsGiu0c 04/07/29 12:26 ID:??? AAS
>>118
>組込型言語とでもいうんですかね。忘れました。

埋め込みSQL(Embeded SQL)ですね。
1-
あと 190 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 1.980s*