2008-09-14 15 views
10

オブジェクト・リレーショナル・マッパーには多くの情報があり、インピーダンス・ミスマッチを避ける方法があります。これらはすべて、オブジェクト・データベースを使用する場合には疑問点です。私の質問は、なぜこれがより頻繁に使用されないのですか?パフォーマンス上の理由、またはオブジェクトデータベースによってデータがアプリケーションに専有化されたり、他の何らかの理由があるためですか?オブジェクトデータベースの長所と短所は何ですか?

+0

だと思います。これはCW – Konstantinos

答えて

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

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

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

+1

であるべきだと思います。親しみやすさに対する反論:開発者が使用しているオブジェクトを永続させているのですが、DB管理者は必要ですか?または、管理者と開発者の間で時間を分割することができるより多くの開発者を雇うことができますか? –

+3

パフォーマンスの反論:berkeleydb;リレーショナルではなく、垂直方向に256テラバイトまで拡大できます。 Memcached;それはリレーショナルではなく、AFAIKを無期限に水平に拡大することができます。 –

+5

成熟度に対する反論:SQLは長く発展していません。それは長い間開発されていません。何人かはCが長年にわたって存在していたので成熟していると言います。私は、C#が成熟していると言います.Cとの共同作業の結果の一部であるためです。 – Guge

1

短所:

  • は も、それはより困難 企業全体で使用する を作り、データストアにアクセスするために同じフレームワーク を使用していないプログラムで使用することはできません。データベース タイプ(すべて コードを変更することなく、異なるDB プロバイダにスワップすることができない)

  • 横切る 非SQLベースのデータベース

  • ためのオンラインで利用可能

  • 少ないリソースは互換性バージョン管理はおそらく の雌犬です。オブジェクトに新しい プロパティを追加するのは、 というよりも、新しい列を テーブルに追加するのが簡単だと思います。

2

オブジェクトデータベースに対する1つの反対意見は、データとコードの間に緊密な結合を作り出すことです。特定のアプリでは、これは問題ありませんが、他のアプリでは問題ありません。リレーショナルデータベースが提供する素晴らしいことの1つは、データに多くのビューを置くことです。

Ted Newardは、OODBMSについてこれ以上多くのことを説明しています。

+0

これは愚かです。この緊密な結合がない場合は、標準のRDBMSエラー率が30%の不良レコードになります。 –

0

ソレン

あなたが述べた理由のすべてが有効ですが、私はOODBMSでの問題は、論理データモデルである参照してください。オブジェクトモデル(あるいはむしろ70年代のネットワークモデル)は、リレーショナルモデルほどシンプルではないため、劣っています。

+0

シンプリシティはデフォルトで優位性を得られません... –

+0

両方とも同等に強力で、この場合はリレーショナルモデルが何かを表すことができるため、シンプルさが優れています。 –

10

I db4oを使用してきたことはOODBであり、それが記載されている短所のほとんどを解決します

  • 熟知 - プログラマは、SQLその後、より自分の言語を知っている(ネイティブクエリを参照してください)
  • パフォーマンス - この1非常に主観的ですが、あなたはPolePosition
  • ベンダーのサポートと成熟度を見てみることができます - OODBの規格があり、あなたがすることができます -
  • 時間の経過を変更することができますすることも同じフレームワークを使用していないプログラムで使用することはできません。 different frameworks
  • バージョン管理はおそらく少しばかりです - バージョン管理は実際にはeasierです!私が興味

長所は、以下のとおりです。

  • ネイティブクエリ - db4oのは、あなたが不足している文字列をタイプミスして、データを見つけることについて心配する必要はありませんので、あなたの静的型付けされた言語でクエリを記述することができます
  • 使いやすさ - ドメイン層、パーシスタンス層(マッピング)、そして最終的にはSQLデータベースのbuissinessロジックを定義することは、確かにDRYに違反しています。 OODBを使用すると、所属するドメインを定義することができます。

私は同意します - OODBは遠く離れていますが、彼らは行きます。 OODBによってより良く解決されたドメインの問題があります。

0

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

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

あなたのデータをドメインモデルに結びつけているのは間違いありませんが、それが重要です!

ドメイン中心のビューを使用して、データ、ビジネスルール、およびプロセスの両方を1つの方法で調べるのは良いことではありませんか?

OODBは、エンタープライズレベルの最もオブジェクト指向のソフトウェアアプリケーションの設計方法と一致し、異なる(リレーショナル)デザインを使用してデータレイヤを設計するための特別な努力はありません。より安価に構築し、維持し、多くの場合一般的に高いパフォーマンスを発揮します。

短所、私は数える成熟度と採用のちょうど一般的な不足...

2

これは、パフォーマンスとは何の関係もありません。言い換えれば、基本的にすべてのアプリケーションはOODBでより優れたパフォーマンスを発揮します。しかし、それはまた、多くのDBAの仕事を失う/新しい技術を習得する必要があります。さらに多くの人々は、データ内のエラーを修正する作業から外れます。 OODBを既存の企業に普及させることはまずありません。 Gavinはまったく無知だと思うが、良いリンクはKirk

+0

Kirk Pepperdineの素晴らしいブログ記事へのリンクは価値がある –

関連する問題