オブジェクト指向データベース - oraccha/omicron GitHub Wiki

リレーショナルデータベースに対するアンチテーゼなんでしょうか．

実装

OODBそのものというより、OODBの活用例(ただしDB系自体が自前)って奴：

MOOD
MetaPhase

e-businessプラットホーム:-)

[http://www.caj.co.jp/jasmine/ Jasmine]

オブジェクト指向リレーショナルデータベースってのもありますね． . 言語の永続記憶拡張が真のOODBの姿ではなく，ちゃんとSQLをオブジェクト指向化した(SQL3の規格に盛り込まれているのかもしれない)

例えば，Postgres の M.R.Stonebraker 教授や ORION の W.Kim 教授とか．
Predator

オブジェクト指向リレーショナルデータベースこそ真のOODBだってな議論があったような気がします．前者はニッチな市場で，後者の方が大規模システムに向いているし，市場的には大きいでしょうね．あと，実際の製品レベルではこれらの違いはほとんど意味がないというか，違いがなくなってきているような気がします．

どこぞの携帯電話会社のシステムがORDBじゃなくOODBだ (ObjectStoreだったかな)、という噂(笑)を数年前に聞いたことがあります。時速500kmのOODBだとか言っていたような (新幹線のすれ違い速度に処理が耐えられるから(笑)。基地局がリアルタイムで切り替わりますよね)。マイナーかも知れないけど小規模とは言えないでしょうね。

Oracleとか銀行のオンライン処理などの基幹系で使われている COBOLとかに比べたら，規模的にどうかなということで，ニッチというのは僕の主観的なイメージで嘘かもしれないです．
OODBって、設計レベル(というかOODやOOA)レベルで"つぼにはまれば"、 RDBと比較にならないくらいに高速になるが、そうでなければ全然旨みがない、とかいう話を(niftyの会議室で(笑))聞いた記憶が。設計がはまれば実装もはまる、という連動した感じなんだそうです。逆にいえば、はまるポイントを見いだす手法がRDBのように定式化されていない分だけ、開発リスクは高いかも、という議論だったような。データの扱い方のアルゴリズムとかの部分が、OODBでは比較的アプリ任せになり、 RDBでは(SQLの自由度より下層では)完全にサーバーに一任なので、そういう差が生まれる、のだとか。
- LispのリアルタイムGCの話で，Unixでヒープ管理を実装するとき，仮想記憶なので，ユーザレベルからはどのページが実記憶に載っているかわからない．ユーザレベルに情報が提供されれば，もっとリアルタイム性をよくできるのにというのを聞いたことがあります． . 同じような話で，RT-Machの連続メディア再生用にページをwire/pin-downするSVCを追加して性能を上げたというのもありました．
- このへんのトレードオフは難しいですね．

リレーショナルDBに落とすときの意味論＆処理効率のボトルネック(=インピーダンスミスマッチ)は、ここ数年で克服された(またはハードが勝手に高性能になった(笑)) ということでしょうか？

あと機能的な議論ですが，JavaのJDBCとかのアプローチがあったり SQLバインディングがあったりで，実際の製品が提供している機能は OODBMSもORDBMSも変わらないのじゃないかなと思ったわけです．
問題なのは意味論の方のインピーダンスミスマッチだと思うんですが，もしかして，これはJDBCでは解決できない?
JDBCはDBMSとJavaを接続する話で，ユーザにどう見えるかは規定していない?
これは私の勘違いですね．JDBCではDBへのアクセスにSQLを使うみたいですね．やっぱり，完全にインピーダンスミスマッチはなくせないか．
SQLを多少隠蔽できるライブラリ(たとえばDelphiのVCL)でも、「ああ、やっぱりテーブルをいじってるんだな」という実感からは逃れられないです。更にもう一段ラップをかませば話は変わるかも知れませんが、 Delphiの抽象化はテーブルオブジェクトを用意する所までなので。それともORDBクラスを試作すると良いのかな(^^;
意味論。Relational理論の世界とOOの世界が違うんですよね。
- OOはデータの同一性を重んじる。対してRelationalは同一性という概念は無い。ひたすら同値だけ。
  - OOでは、select distinctなんて以ての外。技術的にそういう処理は可能だろうが、意味論的になんの意味もない。
  - RDBではdistinctという見なし方に意味が有るところが味噌。
- Relationalならレコード中の任意のカラムだけを切り出して扱うことが多いが、 OOではオブジェクトの任意の属性だけを(検索のとき以外に)切り出して考えるのは''邪道''。
  - というか、レコードとObject、レコードカラムとObject属性、が、似た概念なのかどうかも怪しい。解釈次第だともいえる。
  - たとえば、OO拡張されたSQLで、任意の属性の組を切り出したもの「へ」Methodを実行させることなんて、 OO的に意味が無いでしょう。切り出したものにはクラス(やそれに類する概念)を定義しようが無いんだから。
  - 切り出しを許しちゃったら、ObjectのAtom性を否定したことになる。
  - OO曰く「結合って何？」
    - 勝手に他のObjectとくっつけるんじゃねーよ！
- RDBはデータをいかにバラして捉える(必要に応じてその場で組み合わせる)かが味噌。 OOはデータをいかにまとめる(バラすのを許さない最小単位を決める)かが味噌。
- "関連"の概念も、あまりにも違いすぎる。だいたい"関連させられるもの"の概念が違う。
RDB(SQL)にOO的要素を持ち込むっていう発想は、上滑りにしかならないと思う。小手先レベルで"便利"なものは出来るかも知れないが、それだけ。
- RDBの"一部の"機能だけを使うことにして、かつそのサブセットにOOを馴染ませる、ことは出来ないわけではないだろう。まあそれだけかな。
- 逆に、単に属性とかに基づいた検索が出来たり、検索で見つかったObject(Relationではない)にMethodを実行できたり、というだけの言語ならば、それをRDB(SQL)系言語と呼ぶのは羊頭狗肉でしょう。
- データをめった切りに出来なきゃRDB(SQL)じゃない。めった切りにしちゃったらOOじゃない。

運用事例

[http://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html 九大病院“つまずき"の真相「要件定義の甘さ」が尾を引く] (日経ウォッチャ 1997-12-12) . 今はどうなっているのか知りませんが，日本IBMによる九大病院システム開発の失敗事例です． GemStoneが政治的な理由から使えなくなり，プロジェクトが暗礁に乗り上げたらしいです．どうやらそれがメインの理由ではないみたいですが．
- 直接関係ないけど、上記 MOOD は自由な使用のために既存商用OODBを流用するのを避けた、という記述がありますね。まぁOOPアーキテクチャ自体が風変わりなのかも知れませんが。
- 訴訟責任かあ。病院とかだと特に痛いらしいですよね。生命クリティカルな現場だから。
- まぁ専門家集団だから心配に及ばないんだろうけど、MVCがどこまで徹底できていたのかな？とか、つい思ってしまうです。 OODBの層を相対的にMVC的に捉えることで、特定製品依存性を極力なくすことを、考える必要が有るんでしょうね。
- VBかぁ。クライアントへの処理比重シフトというだけの問題じゃないような凄すぎる方向転換ですねそれは。OOAやOODも完全に捨てた (その頃のVBなら尚更)のかな…
- 要件定義とかコミュニケーションとかの問題は、スパイラル開発とかXPとかでも言及されている問題ですね。顔なりmailなりTikiなり(ぉ)を突き合わせて密なコミュニケーションパスを持つほうが良いんだろうな。まるでオープンソースの専売特許であるかのように言われているけど、実は商売開発でも同様に「客はオキャクサンである限り、良いものは作り難い」んじゃないかなと。
  - XPならWikiを使うのが王道?
- なんかOOと関係ない話が多くなってしまった(^^;
- [http://www.sra.co.jp/smalltalk/SML/1-1000/records/901-1000.htm ここ] の "SYUKAN MAIDASI KINYOBI" のあたりに真相が。
  職場で読まないこと。變な人と後ろ指さされること必死です。
  - バベルの塔ではないですが，設計，開発，運用と話す言葉が違えばプロジェクトの成功は難しいんですねぇ．
    - UML方面なんかでも言うことらしいですが、"かかわる全員が" その言語(そこではUML)を理解してないとしょーがないようですね。さもないと人と人の間でのインピーダンスミスマッチが起きてしまう。

{{{

わたしは、過去の経験から、オブジェクト屋さんが長い間時間かけて設計分析して、美味しい所だけやって、ヤバくなったら残り工程である現場の実装、運用、管理をやらず、他の人に押しつけているケースを見てきました。

それゆえ、オブジェクト屋が絡むプロジェクトについては、色々な面からチェックしています。オブジェクト屋は、エンジニアの中でもスキルが高い場合が多いので、運用、管理を最後までやらないで、次のプロジェクトへ移されてしまう場合が100%です。そして現場が苦労して、最後にはそのシステムを使わなくなってしまうことがあります。 }}}

     * しかし，その後のSmalltalker達の活躍はどうなったのだろう．
        * [Smalltalk](/oraccha/omicron/wiki/Smalltalk)「は」使えない、というレッテルを貼られた、とか？(笑)
          (そうだとすれば、それもまた一種のバベライズですね。
          問題の本質が結局理解されないままに放置されたのかも知れない。)

[http://www.ogis-ri.co.jp/otc/products/objectivity/Example.html Objectivity/DBの導入事例] . セールストークとしてありがちですが，失敗例も得られるものが大きいので公開して欲しいですね．
良い開発が行なわれないから良い事例が生まれない。すると人気も出ない。すると教育もされない。すると益々良い開発がされない。悪循環？(T_T)
- オブジェクト指向そのものはこれだけ隆盛していて、かつソレが駄目だという話はあまり聞かない。
- オブジェクト指向とオブジェクトDBとの(技術的な)距離は相当少ないはず。
- にも関わらずオブジェクトDBだけが隆盛しないなんて…''おかしい''なあ？
  - やっぱり、マーケティングというか宣伝というか煽り(藁)、の有無の問題なんでしょうかね。オブジェクト指向プログラムをSunが(Javaで)煽ったみたいに、権威(藁)が思い切り煽りを入れないと駄目、なのかな？＞世間
  - MSが "Persistent .NET" とか作ってくれればいいのかな？