MongoDBとNoSQLは一般的にはかなり新しいです。私はそれぞれのトピックが多くのコメントを持つことができるコレクションのトピックを持っています。それぞれのコメントには、メタデータとそれ以外のものがあり、Commentsコレクションが役立ちます。MongoDB：他のコレクションにリンクするIDを提供するべきか、コレクションのみを含めるべきですか？
MySQLでは、外部キーを使用してコメントテーブルにリンクしますが、NoSQLではトピックコレクション内にコメントコレクションを含めるか、別のコレクションとリンクIDにする必要がありますか？
ありがとうございます！ マット
によって異なります。
これは、これらのタイプのオブジェクトがどれだけ多くあると思われるかによって異なります。特定のトピックについて、それらをすべて1つのMongoDB文書に収めることができますか？おそらくそうではありません。
それは関係によって異なります.1対多または多対多の関係がありますか？それが1対多数で、関連するエンティティの数が少ない場合は、それらをドキュメント上のIListに埋め込むことを選択するかもしれません。それが多対多であれば、より伝統的な関係を使うことを選ぶかもしれませんし、両者をIListとして組み込むこともできます。
MongoDBのリレーションシップは別々のコレクションでモデル化できますが、データベースにはジョインが存在しないため、コード内でジョインする必要があります。トピックを読み込んでコメントを読み込むことは、パフォーマンスの観点からはうまくいくかもしれません。
その他のヒント：MongoDBので
あなたは書類上のアレイへのインデックスすることができます。だから、インデックスは単にドキュメント上の単純なフィールド（SQLのような）のインデックスであるとは考えないでください。たとえば、トピックのタグコレクションを使用してタグにインデックスを付けることができます。 （http://www.mongodb.org/display/DOCS/Indexes#Indexes-Arraysを参照してください）
データを取得または書き込むときに、ドキュメントの部分的な読み込みと部分的な書き込みができます。 （http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fieldsを参照）
最後に、コレクションとインデックスを使用して必要なものを得る方法がわからない場合は、map reduceを使用してそれを達成することができます。たとえば、現在使用中のすべてのタグを使用頻度でソートして検索するには、使用しているタグを表示する各トピックをマップし、その結果を得るためにそのセットを減らします。その地図の結果を永久に保存し、必要なときに日付を更新するだけです。
NOSQLのアプローチがもたらすスケーラビリティと柔軟性が必要な場合は、リレーショナル・シンキングからかなりのメリットがあります。
Schema Designドキュメント（http://www.mongodb.org/display/DOCS/Schema+Design）もご覧ください。 Mongoサイトにリンクされたスキーマデザインに関するいくつかの10Genプレゼンテーションのビデオ/スライドもあります。概要については、http://www.mongodb.org/pages/viewpage.action?pageId=17137769を参照してください。
オブジェクトの[MongoDBリレーションシップ]の複製が可能です（http://stackoverflow.com/questions/4253496/mongodb-relationships-for-objects） –