Consultas complexas: Recurso de Sistema Excedido

Boa noite Srs.

Utilizo um backend em rede e tem se tornado frequente em algumas máquinas clientes a mensagem de "recurso de sistema excedido" ao carregar minhas consultas ou elas demoram muito para abrir os formulários com base nestas consultas. Preciso utilizar consultas com várias tabelas, e algumas realmente pesadas. Minha dúvida é teórica: o que é melhor para a agilidade do sistema, várias tabelas com mais registros por tabela ou menos tabelas com mais campos por registro?

Para exemplificar o que digo, uma tabela A tem um ID relacionado a tabela B. A tabela B pode ter até 20 registros associados a cada ID da tabela A. No meu caso, eu tenho a opção de transformar cada linha de registro da tabela B em campos de um único registro na tabela A, porém com mais dados por registro. Isso melhora os recursos do sistema?

Caro drcaiocatalani.

O Access tem uma rotina para analisar o banco de dados atual.

No menu "Ferramentas do banco de dados", acesse a opção "Analisar desempenho", ou "Analisar tabela".

Creio que poderá ajudar...

Quanto a pergunta: mais linhas e menos colunas ocupam menos espaço e tem maior desempenho...

Olá caique

Usei o analisador de desempenho e fiz as alterações sugeridas (na maioria apenas relacionamentos no backend que na verdade já existem no frontend) mas não aponta problemas com as consultas. Eu é que percebi que tem muitas consultas mesmo. Consultas baseadas em consultas usando muitas tabelas diferentes... achei que isso fosse a razão do baixo desempenho.
Fiz a pergunta sobre o número de linhas X número de colunas porque percebi que a consulta que mais demorou a abrir é uma baseada em uma tabela com poucos campos (um ID e dois campos numericos) mas muitos registros (115 mil registros).
Preciso reorganizar as idéias...

Obrigado Avelino. Muitas dicas boas! Vou implementar o que for possível!

Veja no link abaixo a maneira correta de dar o tópico por resolvido.
https://www.maximoaccess.com/t860-resolucao-de-topicos#5263

Aguardamos sua ação...