かなり前に、オブジェクト データベースについて聞いたことがあります。クールなコンセプトとすべて。さて、あらゆる場所で ORM のイベントが発生していますが、まだオブジェクト指向データベース システムを使用している人はいますか? 関連性はありますか?それらは実用的ですか?
10 に答える
OO データベースがニッチ市場から抜け出すことはありませんでした。それらは、データ構造がオブジェクト グラフによって表現されるのに適している一部のアプリケーションには適していますが、RDBMS に比べてキャズムを越えるための説得力のある利点はありませんでした。OODBMS 製品の重要な利点は、ホスト言語との緊密な統合です。オブジェクト/リレーショナル インピーダンスのミスマッチはありません。
ただし、 Gemstone、Versant、Cardinalなどの OODBMS ベンダーはまだいくつかあり、自社製品でうまくやっています。このテクノロジは、一部のタイプのデータ構造に役立ち、RDBMS よりも効率的ですが、最新の SQL ダイアレクトと比較してアドホック クエリには弱い傾向があります。
他のさまざまな 人が指摘しているように、Gemstone は、 SeasideとMaglev ( Railsが実行されている Gemstone VM へのRubyのポート) をサポートしているため、少し注目を集めています。これにより、Gemstone の親切な人々が少し報道され、OODBMS パラダイムにもう少し注目されるようになるかもしれません。
実際、データベース システムは、根本的な変更が非常に困難な分野の 1 つです。リレーショナル データベース システムには数十億ドルが費やされており、かなりうまく機能しています。
実生活では、それは単に真実ではありません。データベースに関する問題の主な理由 (すべてのデータベース行の 30% にエラーが含まれているという主張を見ました) は、SQL での非常に原始的な型指定と検証の使用です。また、リレーショナルと名付けられていますが、リレーションの扱いが非常に苦手です。その結果、データモデルが非正規化され、更新エラーが発生します。
ビジネスがリレーショナル データベースを好む理由は、それらが非常に予測可能だからです。彼らはそれらに多額のお金を費やさなければならず、多くの開発者と、主に日常的な仕事を行う保守が必要です。彼らは、排除できる重複の量を利点として認識していません。ルーチン作業により、開発者は困難な作業のリスクを吸収できます。OODB に切り替えると、予測しにくい作業が維持されます。
db4oをチェックしてください。
実際、データベース システムは、根本的な変更が非常に困難な分野の 1 つです。リレーショナル データベース システムには数十億ドルが費やされており、かなりうまく機能しています。それらは実績のある技術であり、ほとんどのニーズを満たすのに十分な柔軟性を備えています (たとえば、あなたが言ったように ORM を使用します)。オブジェクト データベースは実際に存在し、学界の外でも存在します。しかし、すぐにその分野で SQL Server や Oracle のような大規模なものが登場するとは思わないでください。それらは理論として、また小規模なアプリケーション固有のデータベースやさまざまな製品として存在します。基本的に、リレーショナル データベースは、要件をより適切に処理するために、将来的にオブジェクト指向になると予測しています。
最近ジェムストーンを使い始めました。GLASS (Seaside (smalltalk Web フレームワーク) を使用した Linux (または OS-X) 上の Gemstone) は、おそらく複雑なアプリケーションに最適な Web 開発環境です。Smalltalk は「本物のルビー」として復活を遂げています。
スキーマの変更とクエリのサポートは、RDBMS よりもはるかに優れています。
重要な違いは、今回は手頃な価格であることです。
私が取り組んでいる製品では、Versant Object Databaseを使用しています。(以前の FastObjects、以前の Poet データベース)。これはオブジェクト データベースであり、主に構成オブジェクトの格納、Java コードとのインターフェイスなど、製品のいくつかの側面でリレーショナル モデルよりもはるかにうまく機能することがわかりました。
この以前の質問も参照してください: https://stackoverflow.com/questions/52144/object-directional-database-experiences
彼らのソフトウェアのコストを知るのは簡単ではないからです.
私は Objectivity、db4o、versant を調べましたが、いずれも Web サイトにソフトウェアの価格が前もって掲載されていません。
それだけでもうほとんど興味を失った。
これらすべての異なる oodb の価格とライセンスの比較がある場所を知っている人はいますか?
大規模なビジネス アプリケーションに GemStone を使用する。それは素晴らしく、非常に実用的です。私たちは数年間それを使用してきましたが、その間、非常に少ないリソースで多くのことができるようになりました. 残念ながら、オブジェクト データベースには多くの誤解があり、これがビジネスの世界での関連性を低下させていると思います。GLASS (GemStone、Linux、および Seaside Smalltalk) のようなものが将来に向けて変化することを願っています。
オブジェクトデータベースは、これまでのクールなコンセプトです。ただし、実装にはスケーラビリティと安定性の問題があります。これらの2つの獣に対処する正しい化身で、方程式が変わる可能性があります。
私が思ったのは、データエンジン(必ずしもオブジェクトデータベースである必要はありません)とRDBMSは実際に共存できます。実際、中層のデータエンジン、組み込みアプリ/システムなどに最適な場所があります。 、データエンジンを正しく実装すると、低レベルと高レベルの両方のRDBMS/SQL構造のオブジェクト永続性をサポートできるようになります。これは、アプリケーションがオブジェクトの操作、オブジェクトの永続性のためのデータエンジンの使用、およびRDBMSインターフェイスを介したテーブルの行/列としてオブジェクトを使用できるようにすることを選択できることを意味します。
これは理想的な設定です。2つのテクノロジーを橋渡しし、開発者が好みのインターフェースでプログラミングするための代替手段を提供します。これは今あると主張する人もいるかもしれません。たとえば、SQL ServerはCLRオブジェクトのホスティングをサポートしていますが、現在の実装ではインピーダンスの低下に悩まされています。つまり、データパスにはオブジェクトとしての多くの変換/変換があります!= 2次元データ。したがって、オブジェクトを処理するアプリがオブジェクトをDBに保存する場合、ソリューションはそれらをテーブルの行データに変換/変換する必要があります。
しかし、状況を逆にすると、つまり、データエンジンがオブジェクトで動作する場合、インピーダンスの不一致はありません。2次元データプロジェクションを追加することは、オブジェクトコレクションのインターフェイス実装にすぎません。したがって、オブジェクトがテーブルのデータ行として公開されるときに発生するマッピング/変換は実際にはありません。これが私の理論です。
したがって、この分野の次のテクノロジーの波は、オブジェクトを低レベルのインターフェイスおよびその上にあるRDBMSインターフェイスとして使用できるようにするデータエンジンである可能性があります。そして、このテクノロジーは現在利用可能です!
B-Tree Goldバージョン4.0のスケーラブルなオブジェクトの永続性は、これを主要な設計目標として持っています。これは、次の特性を実現しているため、基本的にその上のレイヤーである次のRDBMSに最適なデータエンジンに適しています。その主なポイントの2つは次のとおりです。スケーラビリティ:通常/平均装備のラップトップで17時間に1億回挿入。安定性:DBが破損せず、以前にコミットされた状態にロールバックできることを保証する産業強度トランザクション。
これが機能するためには、データエンジンがRDBMSサーバーに必要なスケーラビリティと安定性を満たしている必要があります。非常に難しい作業ですが、不可能ではありません。B-TreeGoldバージョン4.0SOPはこの要件を満たしているため、SOPは使用方法を自由に選択できるため、この種のソリューションを実際に実行する準備ができています。これは、さまざまな方法で使用できます。たとえば、RDBMSサーバーを中間層のキャッシングステーションとして補完したり、クライアント側にDBを組み込んだりするなど、RDBMSサーバー自体の低レベルのデータエンジンであることは言うまでもありません。
少なくとも私の観点からは、彼らはほとんど死んでいます。しかし、繰り返しますが、私は主に商用ソフトウェアで働いています。学術分野では、まだどこかで使われているのかもしれません。