Se você trabalha com desenvolvimento em ambiente Mainframe, já deve ter ouvido a máxima: "MIPS é dinheiro". No Adabas, a diferença entre uma consulta que roda em milissegundos e um processo batch que arrasta o ambiente inteiro está na forma como você modela e acessa suas chaves de busca.
Muitos desenvolvedores (especialmente os que estão começando no mundo Natural/Adabas) criam chaves de busca de qualquer jeito. O resultado? Consultas que geram leituras sequenciais pesadas, sobrecarregam a Inverted List no Associator e disparam o consumo de CPU.
Hoje, vamos entender o verdadeiro "pulo do gato" da performance no Adabas: a diferença crucial entre Subdescritores e Superdescritores, e como o segundo pode salvar a sua aplicação.
Subdescritor: É uma chave criada a partir de um pedaço de um campo existente.
Exemplo: Você tem o campo DATA-CONTRATO (AAAAMMDD), mas cria um Subdescritor apenas para o ano (AAAA).
Superdescritor: É o verdadeiro campeão da performance. Ele permite combinar múltiplos campos (ou pedaços deles) em uma única chave de busca no Associator.
Exemplo: Você combina COD-CLIENTE + ANO-CONTRATO em um único índice.
Conceito Rápido
Antes de ir para o código, vamos abrir o capô do Adabas e entender o que cada um faz:Subdescritor: É uma chave criada a partir de um pedaço de um campo existente.
Exemplo: Você tem o campo DATA-CONTRATO (AAAAMMDD), mas cria um Subdescritor apenas para o ano (AAAA).
Superdescritor: É o verdadeiro campeão da performance. Ele permite combinar múltiplos campos (ou pedaços deles) em uma única chave de busca no Associator.
Exemplo: Você combina COD-CLIENTE + ANO-CONTRATO em um único índice.
O problema: O FIND com múltiplos campos
Imagine que você precisa buscar os contratos de um cliente específico criados no ano de 2026. Uma abordagem muito comum (e altamente ineficiente) é escrever um FIND combinando campos normais no WITH. O que acontece por baixo dos panos? Quando você faz isso, o Adabas precisa ir até a Inverted List do Associator, ler todos os ISNs do cliente X, depois ler todos os ISNs do ano de 2026 e fazer um cruzamento lógico em memória (um AND de listas de ISNs) para só então devolver o resultado. Se o cliente tiver milhões de registros, o Associator vai sofrer, o consumo de MIPS vai para o espaço e a consulta vai demorar.A Solução: O Superdescritor em Ação
Em vez de fazer o Adabas cruzar duas listas gigantescas no Associator, nós criamos um Superdescritor (vamos chamá-lo de S1) que já nasce com a combinação pronta: COD-CLIENTE + ANO-CONTRATO. Dessa forma, o Adabas não faz cruzamento nenhum. Ele vai direto na árvore de índices do Associator, localiza a chave exata (ex: 123452026) e traz os ISNs instantaneamente. Uma operação que demoraria minutos em arquivos com dezenas de milhões de registros passa a ser imediata.Exemplo Prático em Natural: O Antes e o Depois
Para ficar claro, vamos ver como muda o código e o comportamento do banco de dados. 🔴 Abordagem Ruim (Consome MIPS e gera overhead no Associator) Neste cenário, estamos usando dois campos descritores separados. O Adabas terá que cruzar as duas listas de ISNs em tempo de execução.* TRADICIONAL: Filtro composto por descritores separados
FIND CONTRATOS-VIEW WITH CLIENTE-ID = #CLI-PROCURADO
AND ANO-CONTRATO = '2026'
/* O Adabas lê a lista do cliente, lê a lista do ano,
/* faz a intersecção de ISNs e depois busca no DATA Storage.
DISPLAY CONTRATO-NUM STATUS VALOR
END-FIND
O Pulo do Gato com Superdescritor
Aqui, usamos o Superdescritor SUPER-CLI-ANO (que é a fusão de CLIENTE-ID e ANO-CONTRATO).* OTIMIZADO: Busca direta utilizando o Superdescritor (S1) * O formato da busca concatena as duas variáveis em uma única chave FIND CONTRATOS-VIEW WITH SUPER-CLI-ANO = #CHAVE-COMBINADA /* O Adabas vai direto no endereço exato da combinação. /* Zero cruzamento de listas, resposta instantânea! DISPLAY CONTRATO-NUM STATUS VALOR END-FINDDica de Performance: Repare que no segundo exemplo, a busca lógica no Associator tornou-se de indexação direta. O ganho de velocidade aqui é exponencial conforme o tamanho do arquivo cresce.
Subdescritor vs. Superdescritor
Para não errar na arquitetura do seu arquivo, siga essa regra de ouro:| Cenário | Descritor | Justificativa |
|---|---|---|
| Preciso filtrar relatórios ou telas por apenas uma parte de um campo (ex: apenas o mês de uma data, ou os primeiros dígitos de um CEP). | Sub | Evita que você precise criar um campo redundante no Data Storage apenas para guardar um pedaço de informação. |
| Tenho telas de consulta ou processos batch repetitivos que filtram por dois ou mais campos fixos (ex: Empresa + Filial + Status). | Super | Evita o cruzamento de listas de ISNs no Associator. A combinação cria um atalho definitivo direto para o dado. |



0 comentários:
Enviar um comentário