それが問題です。OODBが失敗した理由、または今日でも多くのシステムがリレーショナルデータベースを使用している理由を1つだけ挙げてください。
14 に答える
主な理由はSQLです。アプリケーションの外部の他のコンテキストでデータベースのデータを使用できると非常に便利です。多くの場合、オブジェクトデータベースでは、データは簡単に照会できない形式で保存されます。リレーショナルデータベースを使用すると、たとえば、データをデータウェアハウスの一部にすることも、システム管理者などがクエリを実行することもできます。
複数回回答できますか?もう1つの理由は、リレーショナルDBが数学に強力な基盤を持っていることです。関係の定義から通常の形式に至るまで、理論は堅実です。リレーショナルモデルがOOにうまくマッピングされていないことは事実ですが、IMHOは、そのモデルの利点と安定性がマッピングの問題を上回っています。
「オブジェクトデータベース」が(ほとんど)誰も持っていない問題を解決しているからだと思います。オブジェクトグラフを単純に永続化するには、ほとんどのOO環境に組み込まれているシリアル化で「十分」です。データのサブセットに対して高度な操作を実行する場合は、リレーショナルデータベースとSQLが最適です。
一部のフリンジアプリケーション(メモリに保持できないが、RDBMSを使用するために関係が単純化されていない巨大なオブジェクトグラフ)を除いて、これらのツールは実際には必要ありません。
OODBが主流ではないという理由だけで、私たちはまだ彼らが持っていた成功を考慮する必要があります。キャッシュとZopeはどちらも(比較的)広く使用されていますが、一部の標準では成功していると見なされます。
おそらく、OODBが劇的に定着しなかった最大の理由は、OODBからの潜在的な市場シェアのほとんどを占めるハイブリッドオブジェクトリレーショナルシステム(PostgreSQLとInformix)の成功によるものです。
これは質問に直接答えるものではないことを私は知っていますが、それは方程式の一部だと思います。とはいえ、全体として、リレーショナルデータベースをサポートする勢いと深く根付いた思考プロセスは、人々が切り替えるのを難しくしていると思います。現在、DBの専門家は、ほぼ独占的にリレーショナル理論のトレーニングを受けており、DBの専門家は、OODBの回避に非常に興味を持っており、学界は、ほぼ独占的にリレーショナルに基づいて実践者にDB理論を教えています。
大企業のDBAや主流の教授やカリキュラム、開発者以外のスタッフがOODBを管理する準備をするまでは、開発側から見ても大衆にアピールすることは難しいと思います。
えーと、おかしいですね。オブジェクト指向の分析と設計の頂点のようなドメイン駆動設計への推進があり、ORMシステムを活用してオブジェクトを永続化するエンタープライズパターンがあります。アプリケーションの設計がオブジェクト指向であり、ドメインに焦点を合わせている場合、OODBがアプリケーションに大きなメリットをもたらすことは私には完全に理にかなっています。
成熟度と取り込みに関する問題は別として、哲学的な観点からは、OODBは有益またはOOアプリケーションのように見えます。初心者のためにそのマッピングレイヤーを維持する必要はありません;)
ただし、ドメインドライブの設計を行っておらず、オブジェクトをデータオブジェクトとして使用していて、ストアドプロシージャが好きな場合は、実際には取得できません;)
RDBMは(強力な理論的基盤に基づいて構築され、はるかに長い間市場に出回っており、多くの場合OODBよりも忠実にデータをモデル化でき、OODBよりも多くのDBAで使用できます)。これが、リレーショナルタプルの形での理由の1つです。
Philの主張を増幅できれば:SQLの標準化。OODBはOQLなどのクエリ言語を試しましたが、真の標準に準拠しているようには見えませんでした。また、おそらく標準化の欠如が原因で、クエリ言語の品質が疑われました。規格は競争を促進し、それが品質を生み出します。
その理由の 1 つは、データベースはデータに関するものであり、オブジェクトは構造とアルゴリズムに関するものです。データを取得してクラスに埋め込んだら、静的構造で関係と操作を特徴付けます。一方、データベースは、アトムの整合性を乱すことなく、データをアトミック テーブルのインスタンスの束に構造化解除して、さまざまな構造 (通常はクラスを使用) に再構築することを目的としています。
データベースは、ヘキサヘキサフレクサゴンにいくらか似ています。
それ、そしてo/r-mappers。これらを通じて、真のOO-DBとの違いははるかに小さくなりますが、前述の利点は引き続き有効です。
費用のかかるテクノロジに関する決定は、技術的な知識を持つ人々によって行われるわけではありません。リレーショナル データベースを使用している企業は、OODB に脅威を感じている多くの人を雇用しているため、OODB について学ぶことを避けています。
OODB の採用が遅れている理由は、主に、リレーショナル SQL データベースの人気や適切性を高めているいくつかの重要な要因に基づいています。純粋なオブジェクト指向データベースは現在、リレーショナル モデルの欠点の多くを克服した状態にありますが、重要な部分がいくつか欠けています。
1 つには、中央データベース管理のサポートが不足している傾向がありますが、これはさまざまな製品で急速に修正されています。
2 つ目の理由は、標準のクエリ言語を実装しているシステムがほとんどなく、代わりにプログラミング言語または特殊なクエリ言語に依存してストア内のデータを取得および操作していることです。これは、NoSQL ベースのソリューションに慣れているプログラマーのまったく異なる考え方に加えて、新しいクエリ言語を学ばなければならない場合、多くの人にとって大きな障害となります。その上、ほとんどの SQL ベース / リレーショナル データベースは現在、オブジェクト指向設計をある程度サポートしています。さらに、選択したプログラミング言語でリレーショナル データベースがすぐに利用できないという問題を「バイパス」するために多くの人が使用する ORM などのラッパーがあります。
しかし、これらの問題は主に企業環境に存在します。小型デバイスの組み込みデータベースとして、Web サイトのストレージとして、航空宇宙などの分野で非常に人気があり、多くの場合、通常のリレーショナル データベースの必要性を完全に置き換えています。
未来がどうなるか誰が知っていますか?
哲学的な理由は二つあると思います。
第一に、人々は伝統的に持続性を実際の機能から分離する傾向があります。オブジェクトの「寿命」を取り除き、主に永続化のために保持すると、それはレコードになり、「寿命のない」データ オブジェクトとして扱う傾向があります。
それに続いて、非常によく似たものの大量のコレクションを考えるとき、人々はそれらをオブジェクトではなくテーブルとして考え始めます。
O/Rで区別がなくなり始めていると思います。たとえば、私は hibernate を使用して、非常に複雑なクラス階層を MySQL データベースにダンプします。ただし、私は自分のプロジェクトでパフォーマンスが重要なものを書いていないので、効率的に行われていないと確信しています。
ほとんどの言語によって提供されるシリアル化により、オブジェクト属性をフラット化できるため、それらを RDBMS に簡単に格納でき、同様にオブジェクトを取得することは大きな問題ではありません。OODBMSの使用を実装するのを妨げる、広くて堅固な基盤がまだ欠けています。
私は現在、これを修士論文プロジェクトとして実行し、今日の RDBMS で一般的に使用されているほぼすべてのコンポーネントをサポートする OODBMS の一般的なフレームワークを提供して、非線形構造の DBMS を提供することを考えています。勉強中に、Java と .net のみに OODBMS を使用する (実装された) アプローチである db4o と呼ばれるプロジェクトに出くわしました。これは、すべてのタイプのプラットフォームと言語に対して一般性を欠くもう 1 つの理由である可能性があります。
オブジェクト指向の動きが勢いを増している間に、オラクルのような大物がリレーショナルデータベースに投資していたからだと思います...オラクル/マイクロソフトが大規模に投資すれば、彼らは主流になるかもしれません...そうする強い理由はありません...それは多くのプログラマーの生活を簡素化します...しかし、「プログラマーの生活をよりシンプルにする」ことは、彼らにとってあまり良いビジネス目標ではありません!