2011-09-09 11 views
6

ほとんどのセクションがユーザプロファイルに依存するWebアプリケーションをコーディングしたいとします。私はMongoDBを使いたいです。私は、主要なプロファイル文書のために約10個の埋め込み可能な文書を作成し、1人のユーザーに関連するすべてを自分の文書の中に保持することを考えていました。MongoDBの埋め込みドキュメントとシステムユーザプロファイルの一意のObjectIdによる参照の比較

mongodbに外部キーを使用する明確な方法はありませんが、唯一の方法はObjectIdの型でフィールドto_do_idを作成することですが、内部的には全く関係ありません。同じIDを照会する必要があります。

  1. トップレベルドキュメント内に埋め込みドキュメントタイプの数が制限されているため、パフォーマンスが低下する可能性がありますか?
  2. あなたは一人一人の視点を提示する際にドキュメントのほとんどが関連しなければならない中央プロファイル文書を持つという問題をどうやって解決しましたか?
  3. MongoDbの内部で半外部キーを使用していますか?ObjectIdタイプのフィールドは、埋め込む代わりに他のドキュメントの一意のIDを持ちますか?

私はどのようなアプローチをとるべきかを感じることができません。どうもありがとうございました!

+0

+1良い質問です。 – Adelin

答えて

2
  1. パフォーマンスに関しては特に制限はありません。ただし、文書が大きくなるほど、ワイヤを介して送信するのに時間がかかります。文書全体が常に検索されます。
  2. 私は参考にしています。単純なマニュアル参照とデータベースDBRefをこのページごとに選択することができます。http://www.mongodb.org/display/DOCS/Database+References
  3. 上記のリンクは、文書内で半外部キー方式で参照する方法を示しています。 DBRefはあなたがしようとしているものには良いかもしれませんが、簡単なマニュアル参照は非常に効率的です。

参考になるアプローチが最も良い一般的な経験則が存在するかどうかはわかりません。私はJavaやGroovyを主に使用しているので、私はDBRefオブジェクトを返すことが好きです。私はこのデータ型をチェックし、それを使って参照を一般的な方法で扱う方法を決めることができます。

私は、同じコレクション内の異なるドキュメントへの参照には簡単な手動参照を使用し、コレクション間の参照用のDBRefは使用する傾向があります。

私は役立つことを願っています。

+0

明らかに、ルールが設定されておらず、コードに対してより便利なものがあります。大規模なドキュメントを転送するという点にはメリットがあります。なぜなら、約10個の埋め込みドキュメントがある場合、選択したフィールドのみを選択するようにアプリに指示しなければならないからです。ありがとう。 –

+0

まあ、スキーマ設計に関するいくつかのベストプラクティスがあり、そのうちのいくつかは参照の使用を参照しています。それは一見価値がある:http://www.mongodb.org/display/DOCS/Schema+Design – dlaidlaw

関連する問題