23

私はプログラミングにかなり慣れていません（大学を卒業したばかりです）。

私は過去4年間、オブジェクト指向開発とこのアプローチの多くの利点について考えてきました。

私の質問は

開発アプリケーションで純粋なオブジェクト指向データベースを使用する方が簡単ではありませんか？

オブジェクト指向データベースがリレーショナルほど普及していないのはなぜですか？

私の観点からは、OOデータベースを使用することは理にかなっています。後者は、テーブル上の複雑なオブジェクトのマッピングに必要な多数の構築を回避します。

4

9 に答える 9

14

過去にオブジェクト指向データベース会社（www.objectstore.com）で働いたことがある-そして現在-私はそれらを素晴らしいものにしているものとそうでないものを作っているものについて公正な洞察を持っていると思います。

素晴らしい：

オブジェクトとリレーショナルの不一致はありません。オブジェクトxをメモリ内の永続ストアに格納する場合、ObjectStoreはほぼリアルタイムの保証でそれを実行できます。当社の製品は、リレーショナルデータベースやORMエンジンでは厳しい厳しい時間要件を満たすために、多くの企業で使用されてきました。

オブジェクトとリレーショナルの不一致はありません。オブジェクトで開発し、オブジェクトで考え、オブジェクトに格納します。

それほど素晴らしい：

ORM：オブジェクトリレーショナルマネージャーは、オブジェクトデータベースをほとんど無関係にしました

スキーマの進化：クラスを変更してフィールドを追加すると、データベース全体をモーフィングする必要があります。ObjectStoreはこれについて何年にもわたって賢くなってきましたが、それでも多くのOODBMSにとって問題となっています。

悪い：

ツールのサポート-これが、OODBMSをほとんどの場所で非スターターにした理由です。今日の誰もがCrystalReports、Access、Excelを利用して、大量のレポートを作成できます。OODBMSを使用する場合は、プログラマーを介してこのロジックを構築する必要があります。設計時に考えていなかったxyzパラメーターを考慮に入れるために予算レポートが必要な場合、これがどれほど速く発生する可能性があるかは誰もが知っています。

ツールは、OODBMSが市場で失敗した理由です。技術的な優位性、パフォーマンス、言語のサポートではありません（ObjectStoreはC ++ / Java / .Netをサポートし、VB、PerlなどのIDispatch言語をサポートするCOMをサポートしていました）。

だから私はここで、特に私が本当に好きな製品について、いくつかの軽蔑的なことを言いました。しかし、ObjectStoreは非常に特定のタスクに優れていますが、Webアプリを構築するための適切な選択ではありません。ある時点では、Amazon.comの在庫管理バックエンドを推進していました。

于 2010-06-08T20:34:35.093 に答える
10

あなたが述べているように、あなたは大学を出たばかりで、The One True (Object-Oriented) Way を熱心に教化されたばかりです。一方、宣言型プログラミング、データベース設計、および集合論を学んだことがある場合は、リレーショナル モデルが完全に適切なアプローチであり、理論に十分に基づいていることに気付くでしょう。一方、オブジェクト指向は、主に産業界で発明されたより実用的なアプローチです。学問ではなく。たまたま、データベースの問題に関する最も興味深い研究開発は、数学のバックグラウンドを持つ人々によって行われています。彼らにとっては、リレーショナル モデルがデータを扱うより自然な方法です。その結果、RDBMS は、オブジェクト指向のものよりも安定性、スケーラビリティ、信頼性に優れている傾向があります。XML によく似たオブジェクト指向データベース

于 2010-06-08T20:38:41.610 に答える
6

数ギガバイトのサイズのリレーショナル データベースが既にあり、20 年分のデータが既に格納されており、数百または数千のテーブルがある場合、このアプローチを使用しても利点はありません。これは、多くのビジネス アプリケーションの現実の世界です。データベースは、特定のアプリケーションのオブジェクト マッピング以外にも使用されます。データベースは、作成したアプリケーションがなくなった後もずっと存在し続けます。リレーショナル データベースは今後 100 年以内に消えることはありません。

于 2010-06-08T19:39:16.267 に答える
2

10年前、私はオブジェクト指向データベースの設計（個人プロジェクト用）を調べたところ、特定の種類の検索を簡単または迅速に実行するのがあまり得意ではないことがわかりました（「姓が「S」で始まるすべての人を検索する」など）。もちろん、オブジェクト指向データベースには必要のないリレーショナルクエリがたくさんあります。また、当時、オブジェクト指向データベースは大規模な展開の準備ができていませんでした（確かに私の関心事ではありませんでした）。新しいものがその問題を修正したと信じていますが、それでも多くのインターシアがあり、リレーショナルデータベースを比較的簡単に使用できる優れたORMがあります。

ただし、リレーショナルデータベースから離れる動きがあります。NoSQLの動きを参照してください。Googleはリレーショナルデータベースを使用していないと思います（オブジェクト指向ではなく、独自仕様で分散されたものです）。

于 2010-06-08T19:57:04.490 に答える
2

実際に表示されるはずの場所にコメントとして追加できなかったことをお詫びします。

しかし、以下は私に対する個人的な攻撃を構成し、私は応答する権利を行使します。

私は実際にはあなたに同意しますが、精神的にはあなたに同意しません。セットベースが唯一の方法であると信じて洗脳されたのはあなただと思います（多分私はあなたの口に言葉を入れています）。

FWIW、私はあなたがおそらく「関係のある宗教的信念」と呼ぶかもしれないものに「洗脳」されていないことは間違いありません。洗脳とは、ある家庭教師が何かを言うときであり、生徒はそれを批判的思考の形をとらずに唯一の真実として盲目的にそして頭を使わずに受け入れます。実際、私はリレーショナルモデルを教えられたことさえありません。実際、私はそれらすべてを自分で発見しなければなりませんでした。意見更新についての伊達の意見に対して、私が厳しい批判を表明したことは事実の記録です。（訂正：「だった」は記録された事実の問題でした。ページは公開されたサイトから削除されたようです。おそらく、Dateが実際に私が批判したビュー更新位置を放棄したという事実と関係があります。）

ですから、私が自分自身を洗脳させたという主張は、まったくの無礼であると言うのには十分な理由があると思います。自由に考えてみてください。しかし、不当で何にも基づかない個人的な意見を公に表明するのであれば、事実に反論されているのを見て認めるのに十分な大人であることを願っています。

階層モデルとネットワークモデルがRMに取って代わられた理由は、この主題に関する本でいっぱいのライブラリ全体に十分に文書化されています。それらを注意深く調べてください。

「キーバリューが市場を引き継ぐ」に関しては、「市場で最も一般的な意見」を完全に自由に取ることができます（つまり、非常に満足している自分自身を考えるのが面倒な愚か者の平凡な大多数）自分自身（および彼らの意見）を、この世界のエリソンとゲイツとジョブズに率いられて、価値のあるものとそうでないものの主要な基準として。個人的には愚かなことだと思いますが、それは私の個人的な意見にすぎません。私はここに、EAVとKey-Valueの恐怖に直面している誰かが彼の職業生活のほぼ毎日行ったいくつかの観察結果をコピーして貼り付けます：

私は、すべてではありませんが、多くの論理テーブルに対して次の「EAVモデル」（少なくとも、私が理解している「EAVモデル」）を使用するアプリケーションに取り組んでいます。

R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}

次の値が表示される場合があります。

R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
     {'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
     {'STATE_CODES', 'ALASKA',  'AK'} ...}

基本的に、「EAV relvars」は、R1およびR2への挿入/更新/削除で作成/変更/ドロップされます（DDLと比較して）。これは、モデル全体の縮小版です。R1とR2には、eav-primary-keys、eav-foreign-keys、ビジネスルールなどを指定するための追加の列があります。モデルの真のフロントエンド」。

今朝、私はシステムAがCODE_XYZがATTRIBUTE2にあると思ったときに生じた、20時間以上の試練に夢中になりましたが、システムBは実際にそれをATTRIBUTE3に定義しました...私は半分聞いていたという事実を笑わなければなりませんでした会話に、そしてEAVに関するこのグループの談話を半分読んでください。

先月、ユーザーが入力した430個のデータポイントのATTRIBUTE16を「2010年5月」から「2010年5月」に変更する緊急アップデート（16工数とアプリケーションの「不良マーク」）を追加する必要がありました。

EAV_RELVARは、テスト/開発で行われたのと同じように本番環境でR1またはR2にコード化されなかったため、コードリリースの約5〜10％に「月曜日の朝のランタイムエラーのクリーンアップ」が伴います（アプリケーションコードとDDLの両方が厳密なバージョン管理のソフトウェア制御...私たちのEAVモデルは、開発者が開発、テスト、および製品で自律的にEAVをセットアップできるようにするため、そのような官僚主義に縛られていません。

昨年、私はR3の主キーの不足に対処するためだけに、レプリケーションソフトウェアのチューニングに3週間を費やしました。

EAV_RELVAR_NAME_zを使用した別のプログラムのパフォーマンスを台無しにしていたため、EAV_RELVAR_NAME_xのATTRIBUTE4にインデックスを付けることができなかったことを一度お詫びしなければなりませんでした。

2年前、R3に参加する必要のある複雑なクエリを永続的に調整するために数百時間を費やした後、DBMSオプティマイザーに統計情報を提供するために、最終的に3か月かけてR3を数百の物理パーティション（EAV_RELVAR_NAMEごとに1つ）に分割しました。たとえば、50個の「STATE_CODES」と200,000個の「LOCATION_CODES」があることを確認する必要がありました。独創的な解決策を祝福しましたが、この変更により、新しいEAV_RELVAR_NAMEを追加すると、関連するパーティションをR3に追加するスクリプトを実行する必要があるという新しいポリシーがあることを指摘したとき、誰もが皮肉を逃しました（はい、DDLを使用）。

私のクライアントは、EAV_RELVAR_NAMEの1つ（すべての適切な制約とセキュリティを適用しながら）のデータをR3にロードするための新しいフロントエンドを望んでおり、ビルドに4か月かかる理由を知りたいと考えています。

R1とR2に対してDMLではなくデータディクショナリに対してdynamic-DDLを使用することで、あらゆる点で優れた方法でEAVシステム全体を書き直すことができるとよく指摘しますが、私たちは常に「コミットしている」と通知されます。 「このアプローチでは（ビルドには7桁の先行投資があり、スタンドアロンテーブルに切り替えるにはコードベースの98％を書き直す必要があります）、その目的は手段を正当化するものではありません。 。

そのようなシナリオがRMの改善であると本当に信じている場合は、ぜひ先に進んでください。ついに壁に頭をぶつけたとき、それがどれほど痛いのか私を責めないでください。

于 2010-06-09T09:10:47.767 に答える
1

オブジェクト指向データベースの採用が非常に遅い理由の1つは、スケーラブルなOpenSourceの選択肢が多くないことです。RDBMSには、たとえばMySQL（Oracleが現在所有）、PostgreSQLなどがあります。

もう1つの問題は、少なくともJavaの場合、RDBMSアクセスのJDBCの標準APIとORM部分のJPAの背後に大きな会社があり、よく知られていることです。オブジェクト指向データベースアクセス用のJDOは標準ですが、それほど一般的ではありません。

オブジェクト指向データベースは、ほとんどの場合、RDBMSよりも強力なAPIまたは言語ロックインを備えています。これが、複数のプラットフォームと言語に投資している大企業がRDBMSにとどまるもう1つの理由です。

私にとって、個人的に人気のあるOpenSource OOデータベースは、それらを試すためにより多くの時間を費やす理由になるでしょう。

于 2010-06-08T20:35:52.490 に答える
1

これには正当な理由はありません。特に、ORM (アクティブ レコード) の使用法が台頭し、マッピングに苦労しているためです。オブジェクト指向データベースは、多くの点で高速で優れています。人気がない理由はニーズです。これまでのところ、RDBMS はうまく機能しており、大企業では「移行」と呼ばれる最大の苦痛を伴います。ほとんどのテクノロジと同様に、ユーザーのニーズが主な目的であり、通常、オブジェクト指向はセールス ポイントではありません。速度はおそらく速いですが、高価なハードウェアと実証済みの RDBMS チューニングにより、パフォーマンスも達成できます。

また、この分野に熟練した人は、再度トレーニングを受ける必要があります (これには多額の費用がかかります)。邪悪な PL/SQL を学んだ高価なコンサルタントは言うまでもありません...

私は、最初のムーバーになると言うでしょう。マハトマ・ガンジーが言ったように、あなたが見たいと思う変化になりなさい。面白いことに、Google でオープン ソースの OO-DB を探したくなりました。

于 2010-06-08T19:46:18.870 に答える
1

データベースは、オブジェクトの保存と取得だけではありません。そうでなければ、OODB とドキュメント DB が世界を席巻していたでしょう。その他の使用状況/側面には、次のものがあります。

  • データを集約し、複雑な一括データ処理/操作を行う。RDBMS はこれに非常に優れています。
  • その他の重要な側面は、並行性/分離 (つまりトランザクション) です。RDBMS は、この分野では非常に成熟しています。
  • もう 1 つの側面は、クエリを高速化するためのインデックス作成です。
  • 上記の "Chris Kaminski" のような別の側面は、データを保持しながら時間の経過とともにスキーマを進化させることができることです。

最後に、業界の慣性が少し進んでいます。大手ベンダーは、クライアントが支払う準備ができていないものにお金を賭ける気がなく、クライアントは大手ベンダーがゲームに参加するまで傍観者として待っています.

于 2010-06-08T20:56:51.997 に答える
0

もう 1 つの問題は、言語サポートです。オブジェクト指向でない言語はどうですか? 優れたデータベースは、言語に関係なく、誰もがアクセスできる必要があります。多くの言語固有のデータベースが失敗するのはそのためです。彼らの市場はその言語の人々だけだからです。

移行要因もあります。MySQL の最大のユーザーは長年のユーザーです。大規模な既存のデータベース システムとは根本的な設計がまったく異なる完全に新しいデータベース システムに移行するのは、非常に費用がかかり、見返りもほとんどありません。

于 2010-06-08T19:52:16.340 に答える