"
Apoiado por

Boas prácticas
INNER JOIN vs FOR ALL ENTRIES vs RANGES artificiais

Uma vez que as operações de dados estão muito mais optimizadas no servidor de base de dados do que no ABAP, é sempre preferível o primeiro. FOR ALL ENTRIES só deve ser usado quando não se conseguir fazer INNER JOIN (como com a BSEG por exemplo). Quando possível, usar RANGES artificiais é preferível a usar FOR ALL ENTRIES mas é preciso cuidado para não ultrapassar o limite do parser de SQL. Depende do servidor de base de dados mas regra geral é de evitar RANGES com mais de 1000 linhas.
Claro que ao usar FOR ALL ENTRIES nunca te podes esquecer de verificar que a tabela interna não está vazia caso contrário todas as entradas da tabela serão lidas.

4 comentários a “INNER JOIN vs FOR ALL ENTRIES vs RANGES artificiais”

  1. José Vília Diz:

    Olá,

    Com tanta informação útil que já retirei deste blog, até me custa dizer, mas a minha metodologia aqui é diferente. Prefiro fazer um FOR ALL ENTRIES. Só em último caso utilizo INNER JOINS e quando o utilizo, nunca faço a união com mais que duas tabelas.

    Quando:
    O nosso cliente tem uma base de dados com largos milhões de registos;
    Temos uma especificação que nos obriga a ir a 15/20 tabelas distintas – ainda que se relacionem todas com chave ou um bom índice;
    Temos milhares de utilizadores e milhares de processos a tentar utilizar o CPU da base de dados em simultâneo;

    Torna-se preferível utilizar o FOR ALL ENTRIES, no meu ver. É claro que esta seleção deve ser feita por índice, e as restantes eliminações feitas no ABAP.

    Prefiro porque a ligação à base de dados do FOR ALL ENTRIES é mais curta do que fazendo um INNER JOIN.

    Em determinados clientes em que já estive, o facto de conseguir trazer os dados rapidamente da base de dados para o ABAP e trabalha-los no ABAP ao invés de dar trabalho à base de dados, mostraram muito melhores resultados, tanto para os meus processos, como para os restantes e até fiquei amigo dos DBAs! :)

    É claro que existem sempre uns pontos a ter em conta na utilização dos FOR ALL ENTRIES:

    1 – Temos que ter um sistema bem configurado: o FOR ALL ENTRIES não faz parte da semântica do SQL, é uma feature do OPEN SQL do ABAP e como tal, antes de o utilizar, devemos garantir que o sistema está bem configurado para uma utilização massiva (notas: 48230 e 634263, por exemplo).

    2 – Como já disse em cima, seleção tem que se feita por um índice com uma boa capacidade de resposta e os restantes resultados eliminados das tabelas internas para que não se baralhe o optimizer da DB.

    3 – Garantir que não temos um grande desdobramento de entradas, por exemplo, vamos a tabela ZTAB_FAE_1 para obter os registos que nos permitem aceder à tabela ZTAB_FAE_2 mas, esta segunda tabela tem 1000 registos por cada um da primeira. Este é daqueles casos em que prefiro utilizar o INNER JOIN.

    Por vezes a diferença não é significativa, mas noutros casos, é a diferença der um JOB a correr 8 horas durante a noite e terminar, ou vê-lo a entrar para dentro do período online sem conseguir ver a luz ao fundo do túnel…

    Cumprimentos,
    José Vília

  2. Wagner Duarte Diz:

    Concordo com o comentário do José Vilia, sempre utilizei metodologias que é preferível FOR ALL ENTRIES. Já fiz diversos teste para comparação de FOR ALL ENTRIES x INNER JOIN e a performace é melhor com FOR ALL ENTRIES. Claro que deletando as duplicidades, e usando chave …

    abs

    Wagner Duarte

  3. Nuno Godinho Diz:

    Interessante. A minha experiência foi sempre a contrária. Em termos teóricos a base de dados está sempre mais optimizada para este tipo de operações. Mas acredito. Provavelmente, como o José refere, deve depender de quão carregado esteja (ou quanta memória livre tenha) o servidor de bases de dados.

  4. Fabiano Diz:

    Olá

    IMHO, SQL bem escrito, SEMPRE será melhor do que um LOOP numa IT com FOR ALL ENTRIES, na minha experiência sempre preferi usar o poder do banco para resolver as coisas do que trazer milhões de registros para a memória e depois ir deletando, sorteando e referenciando.

    Não é a toa que muitos programas em ABAP são lentos, na verdade a maioria dos ABAP’s não conhecem direto SQL, mesmo uma coluna sem índice no banco pode trazer um resultado melhor, visto que o otimizador do SGDB pode fazer cache de tabelas e bitmap scan entre outras técnicas de busca.

    Só vejo motivo se usar algo como FOR ALL ENTRIES se o banco do cliente for um MAXdb da vida, no mais, sempre prefiro o banco, afinal SQL está aí a décadas resolvendo nossos problemas.

    Att,
    Fabiano Machado Dias

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).