Índices secundários em tabelas internas
![images/thumbnail.jpg - Thumbnail](/2016/01/indices-secundarios-em-tabelas-internas/images/thumbnail_hu13507c69ad8dd31e1e3676cf6c3ff12f_33654_300x0_resize_q75_box.jpg)
Durante anos as tabelas internas eram declaradas assim:
DATA: itbl TYPE TABLE OF bkpf.
E depois era fazer SELECT, SORT e tentar usar sempre BINARY SEARCH no READ TABLE. Como o LOOP não permite BINARY SEARCH… usar WHERE com LOOPs não era nada rápido.
Nesta altura as tabelas internas ainda se chamavam todas ITBL.
Entretanto a SAP passou a permitir fazer aquilo que eles chamam de “fully specified internal table”, ou seja, declarar chaves de tabelas internas e a escolher o tipo de organização e índices destas:
DATA: t_bkpf TYPE SORTED TABLE OF bkpf WITH UNIQUE KEY bukrs belnr gjahr.
Com tabelas assim definidas já não é preciso fazer SORT nem usar o BINARY SEARCH porque os índices que definimos são automaticamente usados tanto no READ TABLE como no LOOP, que assim passa a ser rápido.
Até aqui acho que não revelei nada de novo (ainda que, surpreendentemente, vou vendo muito preguiçoso que continua a não declarar a chave nas tabelas internas. Ao menos já lá vai algum tempo desde a última vez que vi uma chamada ITBL).
Mas o que pouca gente sabe é que recentemente a SAP passou a permitir criar índices secundários nas tabelas internas:
DATA: t_bkpf TYPE SORTED TABLE OF bkpf
WITH UNIQUE KEY bukrs belnr gjahr
WITH NON-UNIQUE SORTED KEY key_budat COMPONENTS budat.
Isto resolve as situações em que temos de aceder aos dados de uma tabela interna de mais do que uma forma no mesmo programa.
E para mostrar as virtudes dos índices secundários escrevi um programa que compara uma tabela das velhas acedida com BINARY SEARCH com uma tabela das novinhas com dois índices.
O programa está aqui no GitHub.
Eis os resultados (o tempo de carregamento não está contabilizado no resultado final, apenas os acessos):
É fácil concluir qual é a melhor abordagem.
Obrigado redspotted pela foto.
O Abapinho saúda-vos.