Vous devrez certainement optimiser les requêtes que vous effectuez.
Voici ma meilleure estimation basée sur votre description.
Vous souhaiterez probablement connaître toutes les cartes de crédit de chaque client, conservez donc un tableau de celles-ci dans l'objet client. Vous voudrez probablement aussi avoir une référence client pour chaque paiement. Cela gardera le document de paiement relativement petit.
L'objet Payment aura automatiquement son propre ID et index. Vous souhaiterez probablement également ajouter un index sur la référence client.
Cela vous permettra de rechercher rapidement des paiements par client sans stocker l'intégralité de l'objet client à chaque fois.
Si vous souhaitez répondre à des questions telles que "Quel était le montant moyen payé par tous les clients le mois dernier ?" vous allez plutôt vouloir une carte/réduire pour tout ensemble de données important. Vous n'obtenez pas cette réponse "en temps réel". Vous constaterez que le stockage d'une "référence" au client est probablement suffisant pour ces réductions de carte.
Donc, pour répondre directement à votre question :MongoDB est-il conçu pour préférer beaucoup, beaucoup de petits documents ou moins de gros documents ?
MongoDB est conçu pour trouver très rapidement des entrées indexées. MongoDB est très bon pour en trouver quelques aiguilles dans une grosse botte de foin. MongoDB n'est pas très bon pour trouver la plupart des aiguilles dans la botte de foin. Construisez donc vos données autour de vos cas d'utilisation les plus courants et écrivez des tâches de mappage/réduction pour les cas d'utilisation plus rares.
