10

オブジェクト リレーショナル マッパーや、インピーダンスの不一致を回避する最善の方法に関する情報はたくさんありますが、オブジェクト データベースを使用する場合、これらはすべて問題になるようです。私の質問は、なぜこれがより頻繁に使用されないのですか? それはパフォーマンス上の理由によるものですか、それともオブジェクト データベースによってデータがアプリケーションの所有物になるためですか、それとも何か別の理由によるものですか?

4

7 に答える 7

12
  • 親しみやすさ。データベースの管理者はリレーショナルの概念を知っています。オブジェクトのもの、それほどではありません。
  • パフォーマンス。リレーショナル データベースは、はるかに優れた拡張性を備えていることが証明されています。
  • 成熟。SQL は強力な、長い間開発されてきた言語です。
  • ベンダーのサポート。OODBMS の場合よりも多くのファースト パーティ (SQL サーバー) とサード パーティ (管理インターフェイス、マッピング、およびその他の種類の統合) ツールから選択できます。

当然、オブジェクト指向モデルは開発者にとってより馴染みがあり、ご指摘のとおり、ORM の 1 つを惜しみません。しかし、これまでのところ、リレーショナル モデルがより実行可能なオプションであることが証明されています。

最近の質問Object Orientated vs Relational Databasesも参照してください。

于 2008-09-14T18:11:49.633 に答える
10

私はOODBであるdb4oを使用してきましたが、リストされている短所のほとんどを解決します。

  • 親しみやすさ-プログラマーはSQLよりも自分の言語をよく知っています（ネイティブクエリを参照）
  • パフォーマンス-これは非常に主観的ですが、PolePositionを見ることができます
  • ベンダーのサポートと成熟度-時間の経過とともに変化する可能性があります
  • 同じフレームワークを使用しないプログラムでは使用できません-OODB標準があり、異なるフレームワークを使用できます
  • バージョニングはおそらくちょっとしたことです-バージョニングは実際にはもっと簡単です！

私が興味を持っているプロは次のとおりです。

  • ネイティブクエリ-Db4oを使用すると、静的に型指定された言語でクエリを記述できるため、文字列の入力ミスや実行時に欠落しているデータの検索について心配する必要はありません。
  • 使いやすさ-ドメインレイヤー、永続レイヤー（マッピング）、そして最後にSQLデータベースでビジネスロジックを定義することは、確かにDRYに違反しています。OODBを使用して、ドメインが属するドメインを定義します。

私は同意します-OODBにはまだ長い道のりがありますが、彼らは進んでいます。そして、OODBによってよりよく解決されるドメインの問題があります。

于 2008-10-05T07:01:38.350 に答える
2

パフォーマンスとは何の関係もありません。つまり、基本的にすべてのアプリケーションは、OODB を使用するとパフォーマンスが向上します。しかし、それはまた、多くの DBA を失業させたり、新しいテクノロジーを学ばせたりすることにもなります。さらに多くの人が、データのエラーを修正するために仕事を失うことになります。これでは、確立された企業の間で OODB が普及する可能性は低いでしょう。Gavin はまったく無知のようです。より適切なリンクはKirkでしょう

于 2009-09-25T20:58:32.513 に答える
2

オブジェクト データベースに対する反論の 1 つは、データとコードの間に密結合が生じることです。特定のアプリではこれで問題ない場合がありますが、他のアプリではそうではありません。リレーショナル データベースの利点の 1 つは、データに多くのビューを配置できることです。

Ted Newardはこれを説明し、OODBMS についてはこれよりもはるかに詳しく説明しています。

于 2008-09-14T18:13:44.573 に答える
1

短所：

  • データ ストアへのアクセスに同じフレームワークを使用しないプログラムでは使用できないため、企業全体での使用がより困難になります。

  • 非 SQL ベースのデータベースではオンラインで利用できるリソースが少ない

  • データベースの種類間で互換性がない (すべてのコードを変更せずに別の db プロバイダーに交換できない)

  • バージョニングはおそらくちょっと面倒です。オブジェクトに新しいプロパティを追加するのは、テーブルに新しい列を追加するほど簡単ではないと思います。

于 2008-09-14T18:13:09.053 に答える
0

jodonnel、オブジェクトデータベースの使用がアプリケーションコードをデータにどのように結合するかわかりません。適切に設計すれば、リポジトリパターンを使用してOODBからアプリケーションを抽象化し、ORMでサポートされたSQLデータベースに置き換えることができます。

オブジェクト指向アプリケーションの場合、オブジェクト指向データベースは、オブジェクトを永続化するためのより自然な適合を提供します。

おそらく本当のことは、データをドメインモデルに結び付けることですが、それが核心です！

ドメイン中心のビューを使用して、データ、ビジネスルール、およびプロセスの両方を1つの方法で確認できると便利ではないでしょうか。

したがって、大きな利点は、OODBが最新のエンタープライズレベルのオブジェクト指向ソフトウェアアプリケーションの設計方法と一致することです。別の（リレーショナル）設計を使用してデータ層を設計するための余分な労力はありません。構築と保守が安価で、多くの場合、一般的にパフォーマンスが高くなります。

短所、私が考える成熟度と養子縁組の一般的な欠如...

于 2008-10-06T04:21:38.173 に答える
0

セーレン

あなたが述べた理由はすべて有効ですが、OODBMSの問題は論理データモデルにあると思います。オブジェクト モデル (または 70 年代のネットワーク モデル) は、リレーショナル モデルほど単純ではないため、劣っています。

于 2008-10-04T09:34:48.433 に答える