あなたが提供した情報に基づいて、同じ基盤から始めて、2つの可能なアプローチをお勧めします：
次の場合にこのアプローチをお勧めします：
- 両方の記事ドキュメントとプラットフォームのカーディナリティが高い
-
両方のエンティティを個別に管理しながら、それらの間で参照を同期できるようにする必要があります
// articles collection schema { "_id": ..., "title": "I am an article", ... "platforms": [ "platform_1", "platform_2", "platform_3" ], ... } // platforms collection schema { "_id": "platform_1", "name": "Platform 1", "url": "http://right/here", ... }, { "_id": "platform_2", "name": "Platform 2", "url": "http://right/here", ... }, { "_id": "platform_3", "name": "Platform 3", "url": "http://right/here", ... }
このアプローチは非常に柔軟ですが、コストがかかります。記事とプラットフォームの両方のデータが必要な場合、データは2つの異なるコレクションに分割されるため、MongoDBインスタンスに対してより多くのクエリを実行する必要があります。
たとえば、記事ページを読み込むときに、platformsのリストも表示することを検討します。 、articles collectionへのクエリを実行する必要があります 、次にplatforms collectionで検索をトリガーします platformのメンバーを介してその記事が公開されているすべてのプラットフォームエンティティを取得する sarticle documentの配列 。
ただし、頻繁にアクセスされるplatform attributesの小さなサブセットしかない場合 article documentを読み込むときに利用できるようにする必要があります 、platformsを強化することができます articles collectionの配列 _idに加えてこれらの属性を保存します プラットフォームドキュメントへの参照：
// enhanced articles collection schema
{
"_id": ...,
"title": "I am an article",
...
"platforms": [
{platform_id: "platform_1", name: "Platform 1"},
{platform_id: "platform_2", name: "Platform 2"},
{platform_id: "platform_3", name: "Platform 3"}
],
...
}
このハイブリッドアプローチは、platform data attributesの場合に適しています。 記事固有のデータと一緒に表示するために頻繁に取得するものは、それほど頻繁には変更されません。
それ以外の場合は、platform document attributesに対して行われたすべての更新を同期する必要があります platforms collection内 記事ドキュメントのプラットフォーム配列の一部として追跡する属性のサブセットを使用します。
個々のプラットフォームの記事リストの管理に関しては、両方のコレクションにNからNへの参照を保存することはお勧めしません。前述のメカニズムでは、articles collectionをクエリすることで記事リストを抽出できるからです。 _idで検索クエリを使用する platform documentの値 ：
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
2つの異なるアプローチを提示したので、ここでお勧めするのは、アプリケーションのクエリパターンとパフォーマンスのしきい値を分析し、発生したシナリオに基づいて計算された決定を行うことです。