19
MongoDBのWebサイトでは、MonogDBはドキュメント指向のデータベースであると書いています。したがって、MongoDBがオブジェクト指向のデータベースではない場合、それは何ですか？ドキュメントとオブジェクト指向のデータベースの違いは何ですか？MongoDBはオブジェクト指向ですか？
A
答えて
8
私は、ドキュメント指向のデータベースとオブジェクト指向のデータベースはかなり異なると思います。かなりここで、この上でポストを詳しく説明：
2
ドキュメント指向データベースオブジェクトに異なる概念とリレーショナルデータベースです。 文書データベースにはフィールドが含まれている場合と含まれていない場合がありますが、リレーショナルデータベースやオブジェクトデータベースでは、欠落しているフィールドにはヌルエントリが埋め込まれると予測されます。
データベーステーブルの1つのフィールドにXMLまたはJSON文字列を格納するとします。これは、文書データベースの仕組みと似ています。半構造化されたデータをヌルフィールドをたくさん持たずにデータベースに格納することができます。
3
ドキュメント指向
- ドキュメント（オブジェクト）マップがうまく プログラミング言語のデータ型へ
- 埋め込みドキュメントと配列 のために（スキーマレス）動的型付け
- に参加するための 必要性を減らします簡単なスキーマの進化
- ジョインといいえ（マルチオブジェクト） 高性能トランザクションそして私の理解のMongoDBでは 簡単なスケーラビリティ
は関係なく、それは1つのフィールドまたはn個のフィールドであるドキュメントのようなすべての単一のレコードを扱います。ドキュメント内にドキュメントを埋め込むことさえできます。他のリレーショナルDBシステム（MySQL、PorgeSQLなど）で非常に厳密に制御されているスキーマを定義する必要はありません。私はしばらくMongoDBを使いました。私は本当にその哲学が好きです。
オブジェクト指向は、オブジェクト指向プログラミング（Wikipedia）で使用されるオブジェクトの形式で情報が表現されるデータベースモデルです。
12
これは少し遅れているかもしれませんが、ODBとMongoDBの間には大きな違いがあります。
一般に、ODBの焦点は、DBRefのようなもののコードを使用したり管理したりすることなく、任意に複雑なドメインモデル内のオブジェクト間の単純な参照（関係）です。何千ものクラスがあっても、キーの管理については心配する必要はありません。それらは無料で提供され、実行時に1000個のクラスのインスタンスを作成すると、自動的にデータベースにスキーマが作成されます。コレクションのコレクションを持つ自己参照オブジェクトのようなもののために。
また、トランザクションはこれらの参照にまたがる可能性があるため、完全に埋め込まれたモデルを使用する必要はありません。
管理された永続オブジェクトのライフサイクルであるJPAなどのORMソリューションで活用されているコンセプトは、ODB領域から取得されますが、ODB内にはALLがマッピングされず、データベースの一部であるため、関係を解決するためのランタイムJOINがないため、すべてのリレーションはbツリールックアップと同じ速度で解決されます。 Hibernateを使用している人のために、実行時のJOINの背後にはバックグラウンドがないので、マッピングファイルなしでHibernateを高速化することを想像してください。
また、ODBでは、モデル内の任意の関係を問わずクエリを実行できるため、MongoDBのように特定のコレクションのクエリに制限されることはありません。もちろん、ハッシュ/ bツリー/集約インデックスはサポートされているため、クエリを使用すると非常に高速です。
ODB内の任意のクラスのインスタンスをクラス・レベルで進化させることができ、実行時に正しいクラス・バージョンが解決されます。スキーマレスデータベースの進化によるさまざまな形のBLOB（または値オブジェクト）を扱う方法を決定するためのコードをメンテナンスするMongoDBでの作業とはまったく異なります。あるいは、すべての値オブジェクトを訪問して変更するためのコードを記述します。スキーマを変更したかったのです。
パーティショニングまでは、任意のオブジェクトにまたがって話すことのできるドメインモデルのパーティションモデルを決定するのがずっと簡単だと思います。あなたのコレクションにはMongoDBの文書が含まれていました。微妙な例として、あなたはContactとAddressとShoppingCartを持っています。これらはJSONドキュメントに関連しており、Contact_idによるContactでパーティション化することに決めました。 JSONドキュメントの代わりに、これら3つのクラスを単なるオブジェクトとして扱い、Contact_idにパーティションを持つものをMongoDBと同じように保存することは、絶対にありません。ただし、別のオブジェクト勘定科目があり、アカウントで行われた集計請求処理のために埋め込まれていない方法でそれらを管理したい場合は、ODBで無料で（DBRefタイプのコードを作成する必要はありません） ...あなたは連絡先と一緒にパーティションを分割するか、アカウントを完全に別個の物理ノードに格納することを選択できますが、実行時にアプリケーションのスペースに接続されます...まるで魔法と同じです。
配布、オブジェクトの移動、フォールトトレランス、パフォーマンスの最適化を示すODBを使用してアプリケーションを作成する方法についての本当にクールなビデオを見たい場合はこちらをご覧ください（クールな部分にスキップしたい場合はjump ）で、あなたがアプリケーションの構築を避け、ちょうどそれが既存のアプリケーションに配布し、フォールトトレランスを追加することがいかに簡単であるかが表示されます約21分：
+0
あなたの答えは非常に明確で有用なRobertありがとう。 – Amer
古いの後半コメントのビット回答 - しかし、私の理解は、実際には多くの異なるエンティティ/ドキュメントにまたがる取引に制約を強制することはできません。たとえば、銀行口座からのデビット操作で、その金額を別の口座に振り込むことができます。 –