Le grand principe est de concevoir sur la base d'Access Pattern. Heureusement, nous avons déjà des scénarios d'application typiques.

1. La relation un-à-plusieurs entre l'équipe et le joueur peut être intégrée ou séparée. Cela dépend principalement du fait que ces deux données sont souvent utilisées ensemble. Exemples d'utilisation conjointe : les questions et réponses de SegmentFault sont également un-à-plusieurs, mais sont souvent affichées ensemble. Sinon, vous pouvez le séparer et ajouter le nom du joueur, le _id, le temps de jeu et d'autres informations de base à l'équipe. Ce type de dénormalisation nécessitera un endroit supplémentaire pour être mis à jour lorsqu'il doit être mis à jour. Mais comme la fréquence de mise à jour de ces informations (comme les transferts) est très faible et qu’elles sont beaucoup lues, cela en vaut quand même la peine.

2. Statistiques. Si vous recalculez les données historiques d'un joueur, quel que soit l'inventaire de données utilisé, vous devez parcourir l'intégralité de la base de données, n'est-ce pas ? C'est un autre compromis avant de lire et d'écrire. Évidemment, les mises à jour des données sont bien moindres que les requêtes, la mise en cache des données statistiques est donc significative. De plus, certaines statistiques sont constantes, comme celles d'une équipe sur une saison donnée. Lors de la mise à jour, il peut être mis à jour en temps réel, ou certains résultats intermédiaires peuvent être mis en cache, tels que la valeur moyenne du nombre total et des fois pour faciliter les calculs. Alternativement, une mise à jour une fois par jour après chaque jeu est une possibilité.

3. Les données de chaque jeu sont liées au jeu et aux joueurs, mais sont-elles souvent interrogées auprès d'un certain ? Dans le cas contraire, mais uniquement pour les services statistiques, il est également bon de les placer dans une collection séparée.

4. Les indices peuvent vous aider à trouver des données plus rapidement, mais ils ne peuvent pas vous aider à réduire l'ensemble de données résultant. Une fois le modèle de données conçu, il est naturel de choisir un index.