A menos que eu tenha entendido seriamente, a lógica da pergunta é muito falha
Se houver 20 linhas em B para cada A, 1000 linhas em A implicarão 20k em B. Não pode haver apenas 100 linhas em B, a menos que haja muitas tabelas "AB" com 20k linhas contendo o mapeamento .
Portanto, para obter todas as informações sobre quais 20 das 100 linhas B são mapeadas para cada linha A, você também apresenta a tabela AB. Portanto, isso seria:
- 3 conjuntos de resultados de 100, 1000 e 20k linhas e um cliente
- um único conjunto de resultados JOIN A-AB-B com 20 mil linhas
Portanto, "JOIN" no cliente adiciona algum valor quando você examina os dados. Não que não seja uma má ideia. Se eu estava recuperando um objeto do banco de dados, talvez faça mais sentido decompô-lo em conjuntos de resultados separados. Para uma chamada do tipo relatório, eu a dividia em uma quase sempre.
De qualquer forma, eu diria que quase não há utilidade para uma junção cruzada dessa magnitude. É um péssimo exemplo.
Você precisa se juntar a algum lugar, e é nisso que o RDBMS é bom. Eu não gostaria de trabalhar com nenhum macaco de código de cliente que pense que pode fazer melhor.
Reflexão tardia:
Para ingressar no cliente, são necessários objetos persistentes, como DataTables (em .net). Se você tiver um conjunto de resultados nivelado, ele poderá ser consumido por algo mais leve, como um DataReader. Volume alto = muitos recursos do cliente usados para evitar um JOIN do banco de dados.