2

プロジェクトの開始時に、会社のコレクションを保存し、各会社内に従業員のコレクションを保存したいとします。

ドキュメント データベース (MongoDB など) を使用しているため、構造は次のようになります。

+ Customers[]
   +--Customer
      +--Employees[]
         +--Employee
         +--Employee
   +--Customer
      +--Employees[]
         +--Employee

将来的に、一部の従業員が複数の会社で働くという新しい要件が追加された場合はどうなりますか?

文書データベースでこの種の変更をどのように管理するのでしょうか?

ドキュメント データベースの単純さは、簡単に変更できない壊れやすいデータ構造を作成するため、最悪の敵になりませんか?

上記の例では、変更スクリプトを実行して新しい「Employees」コレクションを作成し、すべての従業員をそのコレクションに移動する必要がありますが、何らかの関係キー (各従業員の CompanyID など) を維持します。

上記を徹底的に行った場合、多くのコレクションがあり、階層がほとんどなく、ドキュメントがキーによって結合されることになります。

その場合、ドキュメント データベースをそのまま使用できますか?

リレーショナル データベースのようになっていませんか。

4

2 に答える 2

3

MongoDB について具体的に言えば、データベースはリレーショナル データベースのような関係を強制しないため、このようなあらゆる種類のデータの整合性を維持する必要があります。多くの場合、これは非常に役立ちますが、この種のことを処理するためにより多くのアプリケーション コードを作成することになります。

とはいえ、MongoDB のようなシステムを使用する鍵は、MongoDB に適合するようにデータをモデル化することです。上記の内容は、MySQL を使用している場合は完全に理にかなっています... Mongo を使用している場合、リレーショナル データベースのようにデータを構造化すると、絶対に問題が発生します。

Employees1つ以上で働くことができる人がいる場合Companies、私はそれを次のように構成します:

// company records
{ _id: 12345, name : 'Apple' }
{ _id: 55555, name : 'Pixar' }
{ _id: 67890, name : 'Microsoft' }

// employees
{ _id : ObjectId('abc123'), name : "Steve Jobs", companies : [ 12345, 55555 ] }
{ _id : ObjectId('abc456'), name : "Steve Ballmer", companies : [ 67890 ] }

にインデックスを追加するemployees.companiesと、特定の会社で働くすべての従業員を非常に高速に取得できます...勤務している会社の数に関係なく。従業員ごとに会社の短いリストを維持する方が、会社の多数の従業員リストを維持するよりもはるかに簡単です。会社とそのすべての従業員のすべてのデータを取得するには、2 つの (高速な) クエリが必要です。

ドキュメント データベースの単純さは、簡単に変更できない壊れやすいデータ構造を作成するため、最悪の敵になりませんか?

シンプルさにはうんざりするかもしれませんが、後で更新したり変更したりするのはとても簡単です。Javascript を介して変更をスクリプト化し、Mongo シェルを介して実行できます。

于 2011-05-27T00:45:40.367 に答える
1

この質問に対する私の最近の回答は、RavenDb コンテキストでこれをカバーしています。

RavenDB のようなドキュメント指向のデータベース システムで階層的かつリレーショナルなデータをモデル化するにはどうすればよいでしょうか?

于 2011-06-09T09:11:03.163 に答える