Limites do AdvPL – parte 02

Introdução

No post anterior, vimos alguns limites como o limite de Strings em AdvPL, e limites de precisão numérica. No post de hoje, veremos alguns limites já publicados oficialmente na TDN, porém vamos ver também as “entrelinhas” destes limites. Vamos partir de alguns limites documentados na TDN, no link http://tdn.totvs.com/pages/viewpage.action?pageId=25165915

Tabela de Dados

Uma tabela na base de dados possui diversos limites que podem ser atingidos, não somente número de campos por tabela ou número de registros. Por exemplo, atualmente o Protheus ainda dá suporte ao formato DBF (até Protheus 11, para as versão 32 Bits do APPServer), e arquivos da RDD CTREECDX (c-Tree Microsiga Edition, da Faircom), e da RDD TOPCONN 00 armazenados em bancos relacionais homologados, acessados através do DBACCESS. Para cada banco de dados Homologado, existem limites intrínsecos do SGDB. Por exemplo, o AdvPL suporta até 1000 campos por tabela, porém além de não ser uma boa pratica colocar tantos campos na mesma tabela — é preferível fazer uma normalização), existe um limite de tamanho de registro. Se eu não me engano, em uma linha de dados, considerando apenas os tipos CDNL (Caractere, Numérico, Data e Lógico), o limite de tamanho de registro dos bancos relacionais homologados não ultrapassa 8 KB. Somente é possível atingir o limite astronômico de 1000 campos por tabela se a soma dos tamanhos dos campos for inferior a 8 KB. Outro limite interessante é o número de registros. A linguagem AdvPL oficialmente têm o limite de 1 Bilhão de registros por tabela, porém cada RDD possui o seu limite de armazenamento. Bancos relacionais em versão EXPRESS, além de não serem homologados oficialmente para uso com o ERP, possuem limite de tamanho da Base de Dados, e as RDDs ADS e c-Tree possuem limites acima de 4 GB, porém desde que o sistema de arquivos utilizado no sistema operacional também suporte tabelas com mais de 4 GB.

Mais limites de dados

O tamanho máximo de um campo do tipo “C” Caractere para uma tabela do AdvPL pode até chegar a 1 KB, mas não é recomendado chegar perto desse limite. O campo do tipo “M” Memo, usando a RDD TOPCONN pode ser expandido até 1 MB. Porém os limites da base de dados não param por aí … Para a criação de índices, cada SGDB / RDD homologada possui um limite de índices por tabela, um limite de campos na chave de índice, um limite de tamanho da expressão de índice e um limite do conteúdo da chave de índice. Como o ERP é homologado para diversas RDDs e SGDBs, estes limites precisam ser “nivelados por baixo” — O menor homologado prevalece. Mesmo que o SGDB que você use, e até o AdvPL aceite extrapolar algus limites, o fato de atingí-los pode prejudicar seriamente uma portabilidade de um SGDB para outro. O limite de índices é uma característica exclusiva da RDD e/ou SGDB utilizados, ainda não testei todos, mas são suportados mais que 16 índices. Porém, deve sempre ser colocado em foco que o SGDB ou RDD precisam atualizar cada um destes índices quando um novo registro é inserido, e no caso de uma aleeração de campos, cada chave de índice que contém um campo alterado será atualizada no momento de fazer um Update.Existem aplicações que podem efetivamente precisar de um número maior de índices para priorizar o desempenho na busca de dados. Porém, deve-se levar em conta que não há mágica. Mesmo sabendo que, para cada índice adicional criado existe um custo maior de manutenção dos índices, quando a velocidade de busca têm prioridade, arca-se com o custo de da manutenção dos índices para ter desempenho na busca. A expressão de índice não deve ultrapassar 250 caracteres, e o tamanho da chave (resultado da avaliação desta expressão) também não deve ultrapassar 250 bytes. Por exemplo, uma tabela com três campos caractere de 100 bytes cada, ao criarmos um índice com CAMPO1+CAMPO2+CAMPO3, a expressão de índice possui apenas 20 bytes, mas a chave resultante desta expressão vai ter 300 bytes. Existem também limites do AdvPL, colocados para que um único processo não cometa “exageros”, como por exemplo o limite de registros em estado de LOCK simultâneos mantidos pelo mesmo processo (Soma de todos os locks mantidos em todas as tabelas abertas em um processo, independente da RDD). Este limite é fixo em 10000 registros, mas em casos realmente especiais pode ser alterado mediante configuração especifica no APPServer. O número de arquivos (ALIAS) abertos simultaneamente também tem um limite no AdvPL. Até o Protheus 10, o limite eram 250 alias abertos. Para o P11 e versões superiores, o limite default foi aumentado para 1024 ALIAS. Quando usamos a RDD TOPCONN, podemos submeter Queries ao SGDB, porém existe um limite de colunas de retorno, fixo em 250 colunas. Parte-se do princípio que, se você precisa de mais de 250 colunas em uma Query, você precisa rever seus conceitos e mudar a abordagem do seu algoritmo.

Memória e Runtime

Os limites de memória são muito interessantes. Alguns são intrínsecos a plataforma (Versão e Plataforma do Sistema Operacional) e a versão do executável do APPSErver (32 ou 64 bits), e outros limites são intrínsecos da linguagem. Têm um artigo na TDN, no link http://tdn.totvs.com/pages/viewpage.action?pageId=6065041, dedicado a explicar melhor alguns destes limites. As variáveis de memória possuem limites bem grandes. Podemos ter programas com até 4096 variáveis, e no caso de Arrays no AdvPL, os limites foram bem esticados. O limite de dimensões de um Array, embora esteja documentado como “ilimitado”, não ultrapassa 32 mil dimensões — um número praticamente inatingível, a menos que o programa esteja fazendo algo de errado; Já o número de linhas de Array, originalmente 4096, foi “esticado” para 100 mil, porém isto pode comer memória com farinha, e como uma instância do APPServer têm um limite de alocação de memória na camada do Sistema Operacional, caso mais de um processo que consuma muita memória seja executado no mesmo APPServer, isto pode atingir o limite do processo e derrubar o APPSErver. O número de procedimentos e funções por programa também foi documentado como “ilimitado”, quando na verdade o termo correto seria “inatingível”, somente um programa muito absurdo conseguiria declarar, dentro do mesmo fonte, mais de 32 mil funções, sem estourar o limite de 1 MB de texto para um arquivo fonte em AdvPL (extensões PRG, PRW ou PRX). O limite para empilhamento de funções no AdvPL (função que chama função que chama função…) é de 250 chamadas empilhadas, e este limite é realmente grande. Utilizando-se de outras abordagens de algoritmo, é possível implementar recursividade no código sem aumentar a pilha de chamada de funções. A nomenclatura das variáveis no AdvPL ainda é de 10 caracteres, ignorando os demais caracteres excedentes. Logo, você pode declarar uma variável nomeada “cNomeDaCidade”, e na hora de recuperar o valor desta variável, chamá-la de “cNomeDaCid”, ou vice-versa, pois somente os 10 primeiros caracteres do nome são significativos. Da mesma forma, nomes de funções, classes e métodos de classes também estão sujeitos por compatibilidade ao limite de 10 caracteres significativos. Por isso, cuidado ao nomear USER FUNCTIONS, pois o prefixo USER FUNCTION é traduzido para “FUNCTION U_”, usando dois caracteres do nome da função, deixando apenas 8 caracteres para você efetivamente nomear a função.

Outros limites

O sistema de arquivos utilizado pelo sistema operacional também possui limites, normalmente bem acima do recomendado pelas boas práticas de programação e estruturação de sistemas, como limites de nome de arquivo (considerando o path completo ), no NTFS ( Windows ) por exemplo é perto de 250 caracteres. Pode existir também limite de arquivos por pasta, mas normalmente são suportados facilmente 32 mil arquivos ou mais — porém chegar perto destes limites pode tornar as operações de busca e manutenção no sistema de arquivos muito lentas dentro destas pastas.

Conclusão

Saber quais são os limites da ferramenta que você escolhe são fundamentais quando falamos em unidades como “Terabytes” de dados e volumes consideráveis de processamento. Porém, deve-se sempre levar em conta que, normalmente não é boa prática chegar perto de alguns destes limites. Isso pode exigir um custo maior em projetar e desenvolver um algoritmo, mas definitivamente isso pode representar ganhos significativos em escalabilidade, desempenho e portabilidade. “Não existe pedra tão grande que não possa ser triturada em um moedor de carne. Basta quebrar a pedra maior em pedras menores sucessivamente, até você obter pedaços que caibam no moedor :D” Até o próximo post, pessoal 😉