Sur la base des informations que vous avez fournies, je recommanderais deux approches possibles, en partant du même principe :
Je recommanderais cette approche si :
- Vous avez une cardinalité élevée des deux documents d'article, ainsi que des plates-formes
-
Vous voulez pouvoir gérer les deux entités indépendamment, tout en synchronisant les références entre elles
// 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", ... }
Même si cette approche est assez flexible, elle a un coût - si vous avez besoin à la fois de données d'article et de plate-forme, vous devrez envoyer plus de requêtes à votre instance MongoDB, car les données sont divisées en deux collections différentes.
Par exemple, lors du chargement d'une page d'article, en considérant que vous souhaitez également afficher une liste de platforms , vous devrez lancer une requête sur la articles collection , puis déclencher également une recherche sur la platforms collection pour récupérer toutes les entités de la plateforme sur lesquelles cet article est publié via les membres de la platform s tableau sur le article document .
Cependant, si vous n'avez qu'un petit sous-ensemble d'attributs platform fréquemment consultés que vous devez avoir à disposition lors du chargement d'un article document , vous pouvez améliorer les platforms tableau sur la articles collection pour stocker ces attributs en plus du _id référence aux documents de la plateforme :
// 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"}
],
...
}
Cette approche hybride conviendrait si les platform data attributes que vous récupérez fréquemment pour les afficher avec les données spécifiques à l'article ne changent pas souvent.
Sinon, vous devrez synchroniser toutes les mises à jour apportées aux platform document attributes dans la platforms collection avec le sous-ensemble d'attributs que vous suivez dans le cadre du tableau de plates-formes pour les documents d'article.
En ce qui concerne la gestion des listes d'articles pour les plates-formes individuelles, je ne recommanderais pas de stocker les références N à N dans les deux collections, car le mécanisme susmentionné vous permet déjà d'extraire des listes d'articles en interrogeant la articles collection en utilisant une requête de recherche avec le _id valeur du platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Après avoir présenté deux approches différentes, je vous recommande maintenant d'analyser les modèles de requête et les seuils de performances de votre application et de prendre une décision calculée en fonction des scénarios que vous rencontrez.
