Sauf si j'ai sérieusement mal compris, la logique de la question est très imparfaite
S'il y a 20 lignes dans B pour chaque A, 1000 lignes dans A impliquent 20k lignes dans B. .
Donc, pour obtenir toutes les informations sur 20 des 100 lignes B qui correspondent à chaque ligne A, vous tablez également AB. Donc ce serait soit:
- 3 jeux de résultats de 100, 1000 et 20k lignes et un client JOIN
- un seul jeu de résultats JOINed A-AB-B avec 20k lignes
Ainsi, "JOIN" dans le client ajoute une valeur quelconque lorsque vous examinez les données. Non pas que ce ne soit pas une mauvaise idée. Si je récupérais un objet de la base de données, il serait peut-être plus logique de le décomposer en ensembles de résultats distincts. Pour un appel de type rapport, je l'aplatirais presque toujours en un seul.
Dans tous les cas, je dirais qu'il n'y a presque aucune utilité pour une jointure croisée de cette ampleur. C'est un mauvais exemple.
Vous devez REJOINDRE quelque part, et c'est ce pour quoi les SGBDR sont bons. Je n'aimerais pas travailler avec un singe de code client qui pense pouvoir faire mieux.
Après coup:
Pour rejoindre le client, il faut des objets persistants tels que DataTables (en .net). Si vous avez un jeu de résultats aplati, il peut être consommé via quelque chose de plus léger comme un DataReader. Volume élevé = beaucoup de ressources client utilisées pour éviter une jointure de base de données.