33

関係データベースがオブジェクト指向データベースよりも一般的なのはなぜですか?

オブジェクト指向プログラミング パラダイムがこれほどまでに広まっているのであれば、OODBMS をたくさん目にするべきではないでしょうか? RDBMS+OR/M よりも優れたパフォーマンスを発揮するのではないでしょうか?

4

9 に答える 9

21

私が見た最大の問題は、標準化の欠如です。RDBMSの世界では、SQLを知っていれば、ランダムなデータベースでかなり遠くまで行くことができます。それらは基本的にすべてそれを実装しますが、わずかな違いがあります。SQLを実行しない既存のRDBMSは1つもわかりません。「RDBMS」と「SQL」は、ほぼ同じ意味で使用できます。

OODBMSに最も近いのは、おそらくOQLであり、これは完全な失敗でした。

これまでにその多くを実装したデータベースはありません。私は数年前にかなり素晴らしい商用OODBMSを使用しましたが、（2007年頃の時点で、メジャーバージョン8または9でした）、名前によるオブジェクトのクエリもサポートしていませんでした。マニュアルには、OQLのこの部分はまだ理解されていないと簡単に書かれています。（わかりませんが、ネイティブコールにドロップダウンしてそれを行うことができた可能性があります。）

私が最近見たほとんどのオブジェクトデータベースには、OQLのようなクエリ言語ではなく、母国語のインターフェイスがあります。たとえば、私が使用したシステムは、PerlとVB、IIRCをサポートしていました（のみ！）。視聴者を2、3の言語に制限する（または、私たちが行ったように、ラッパーを作成するように強制する）ことは、友達を獲得する方法ではありません。

このため、競争はなく、したがって簡単なバックアップ計画はありません。データをMS-SQLに配置し、Microsoftがサポートを停止した場合は、データをPostgresにダンプして、クエリを移植することができます。それほど問題はありません。（クエリが多い場合は、大変な作業になる可能性がありますが、それができることは間違いありません。苦痛ですが、技術的には難しいことではありません。）または、Oracle、MySQL、またはその他の多くの商用と無料。

OODBMSにはそのようなものは存在しません。使用しているものが腹を立てたり、役に立たない方向に進んだり、必要な主要機能が不足している場合は、単にダンプすることはできません。データを競合するOODBMSに移植し、クエリを移植します。代わりに、コアライブラリを変更し、アーキテクチャを大幅に変更することについて話しています。現実的には、本当に信頼できる商用OODBMS（1つでも名前を付けることができますか？）、または状況が悪化したときにチームが維持することを信頼するオープンソースOODBMSに制限されます。

これがFUDのように聞こえる場合は、申し訳ありませんが、私はそれを意図していませんでした。しかし、私はそこに行ったことがあり、プロジェクト管理の観点からは、プログラミング環境が素晴らしい場合でも、戻ることを躊躇します。別の見方をすれば、それがどんなに良い考えであるにも関わらず、今日どれほど人気のある関数型プログラミングであるかを見てください。OODBMSはそのようなものですが、コードだけでなく、コードとデータでもあるため、さらに悪いことになります。今日はErlangで大規模なプロジェクトを喜んで開始しますが、それでもOODBMSを使用することを躊躇します。

OODBMSベンダー：これを変更するには、競合他社に簡単に任せる必要があります。OQLを掘り下げて実際に実装することも、ODBCなどのAPIレベルで実装することもできます。標準のダンプ形式（JSONを使用しますか？）、およびいくつかのOODBMSの形式との間でインポート/エクスポートするためのツールでさえ、すばらしいスタートです。

于 2009-11-14T22:34:52.290 に答える
16

多くの場合、データはプログラムよりも長く存続し、重要です。そのため、今日グリーンフィールド開発を開始したとしても、全体像を考慮する必要があります。RDBM システムで作業するツール、プロセス、および経験豊富な人々が増えています。プログラムを超えて、キャパシティ プランニング、データ マイニング、レポート作成、ETL、他のデータ ソースとの統合などについて考えてみてください。あなたの会社が別の会社を買収し、そのすべてのリレーショナル データをプログラムに取り込むことはどうでしょうか。RDBMS と関連ツールは非常に定着しており、実績があり、強力であるため、他のツールを使用することに戦略的な意味はありません。いくつかの小さなニッチではそうかもしれませんが、一般的にはそうではありません。

于 2009-08-29T01:04:51.647 に答える
4

些細な例では、OODB と RDB は大きく異なる場合があります。特に、すべてのデータを簡単に一度にメモリに読み込んで、一度にすべて書き出すことができるほど少量のデータで作業している場合は特にそうです。しかし、究極的には、OODB は非常に RDB に似た形式でデータを保存する必要があります。それらはそれほど違いはありません。

アプリケーションで使用されるオブジェクトの任意のグラフを考えてみましょう。各オブジェクトは、他のいくつかのオブジェクトから参照される場合があります。オブジェクトのグラフを保存する場合、オブジェクトが参照されるたびにオブジェクトを繰り返し保存することは望ましくありません。1 つには、何らかの種類のループまたは自己参照がある場合、save-object メソッドは無限ループに入ります。しかし、一般的なケースでは、スペースの無駄です。代わりに、重要なデータ ストアでは、格納されるオブジェクトごとに一意の識別子 (キー、通常は RDBMS 用語では代理キー) を宣言する必要があります。それを参照する他の各オブジェクトは、オブジェクト タイプとキーを保存します。オブジェクト全体を繰り返し保存するわけではありません。ここでは、非 RDB オブジェクト ストアに外部キーを再作成しました。

次に、別のオブジェクト (B) に関連するオブジェクト (A1、A2、A3...) のリストを保存したいとします。オブジェクト自体を 2 回保存する代わりに、キーを保存することは既に確立しています。しかし、オブジェクト A1、A2、A3... のキーをオブジェクト B に保存しますか? それとも、オブジェクト B のキーを A に保存しますか? それらを最初の方法で保存し、必要な A がすべて揃っている場合は、関連する B をすばやく取得できます。2 番目の方法は逆です。しかし、どちらの方法も一方通行です。保存したものの逆を照会したい場合、オブジェクトが XML または JSON として保存されている場合、各ファイル内のキーを見つけるために最も無関係な情報を解析するのは非常に非効率的です。テーブルの列のように、フィールドごとに区切られた形式で保存した方がよいのではないでしょうか。

多対多の関係、または双方向で多数のオブジェクトを見つける必要がある場合、この戦略は非常に非効率的になります。唯一の効率的な解決策は、ファイルが A のキーと B のキーで構成されるように、リレーションシップごとに 1 つのファイルを使用して、リレーションシップを格納するヘルパー オブジェクトを作成し、すばやく検索できるようにすることです。相互参照テーブルを再発明しました。

列を持つテーブル、一意の識別子 (キー)、相互参照テーブル... これらは、オブジェクトを効率的に取得できる方法で格納するための基本的なニーズです。うーん...おなじみのように聞こえますか? リレーショナル データベースはまさにこの機能を提供します。さらに、バックアップ、レプリケーション、クラスタリング、クエリなどに最適なツールを使用して最速のデータ ストレージと検索を提供するために、複数のベンダーが何十年にもわたって競争してきました。そして最終的には、RDBMS は基本的に効率的なオブジェクト ストレージの問題に対する非常に優れたソリューションであると言っています。

これが、効率的な RDBMS ストレージ システムにオブジェクト指向インターフェイスを配置するために、Hibernate のようなものが存在する理由です。他の種類のストレージが本当に優れているのは、さまざまな問題領域です。

  • あらゆる種類の非構造化ドキュメント ストレージ (ブログ、ソース管理、または行と列にマップできないもの) には、さまざまな NoSQL データベースが理想的です。
  • 照会しやすいが意味のある変更履歴 (ソース管理の diff など) を保持することは、RDB ではあまり適切ではありません。Datomic のようなものが、ここで新しい領域を築いている可能性があります。
  • オブジェクト グラフが単純または小さい場合は常に、データベースのオーバーヘッドは必要ない場合があります。

OODB は根本的に異なるわけではないため、RDB よりも優れたパフォーマンスを発揮することはできません。
RDB が定着する理由は、オブジェクトの大きなグラフを保存と取得の両方で空間効率と時間効率に優れた方法で保存し、フォールト トレラントでデータの整合性をある程度保証することが、RDB が解決するように設計された問題だからです。最初の場所。これが、JPA と Hibernate がここに留まる理由です。オブジェクト モデルとリレーショナル データ モデルの間のギャップを埋めるためです。メモリ内での操作を容易にするオブジェクト モデルと、持続性のためのリレーショナル モデル。

于 2012-12-03T14:50:05.303 に答える
3

一言で言えば相互運用性(金曜の夜のビッグワード <G> )

ほとんどの企業は、RDBMS で実行されているレガシー システムを使用する必要があります。OODBMS を使用する場合でも、特定の機能のために RDBMS にアクセスする必要があります。データへのアクセス方法は 2 つよりも 1 つの方が簡単です。

OODBMS の世界で Oracle や SQL Server などのビッグネームがあり、さまざまな環境で実績のあるパフォーマンスがあれば、それらを使用するプロジェクトが増えるでしょう。

于 2009-08-29T00:57:44.137 に答える
0

のケースだと思います

壊れていない場合は、変更しないでください。

リレーショナル データベースは非常に根深いものです。

于 2009-08-29T00:45:36.530 に答える