Chaque "aller-retour" vers la base de données aura des frais généraux. Donc, moins il y a d'allers-retours, moins il y a de frais généraux. Considérez également que moins de requêtes signifie moins de paquets du client au serveur. Si le résultat de la requête consolidée vous donne exactement ce que vous voulez, alors la requête unique est la solution. Si votre requête unique renvoie des données supplémentaires ou redondantes (peut-être à cause de la dénormalisation), les économies de frais généraux d'un seul aller-retour peuvent être perdues dans les données supplémentaires transférées.
Une autre considération est la latence. Si les requêtes doivent être complétées dans l'ordre parce qu'une partie de la sortie de l'une est nécessaire dans l'entrée de la suivante, la consolidation en une seule requête supprimera toutes les latences du réseau entre toutes les requêtes individuelles plus petites, de sorte qu'un résultat final peut être livré plus rapidement. Cependant, si les requêtes plus petites sont indépendantes les unes des autres, les lancer en parallèle peut obtenir tous les résultats plus rapidement, bien que moins efficacement.
Conclusion :la réponse dépend des spécificités de votre situation. La meilleure façon d'obtenir une réponse sera probablement d'implémenter les deux méthodes, de tester et de comparer l'utilisation des ressources de chaque implémentation.