Frameworksp

Páginas filhas
  • Limite de campos por tabela

Descrição

Limite de campos por tabela

Observações

O número máximo de campos que podem ser criados em uma tabela é de 350. Essa é uma limitação estrutural do Protheus para garantia do funcionamento e compatibilidade com os bancos de dados homologados.

Caso seja necessário a utilização de um número maior de campos, é recomendável o uso de tabelas auxiliares. As tabelas auxiliares criadas por usuário devem possuir tratamento para ser consultada / alimentada via pontos de entrada contidos na rotina em questão, para desta forma, servir como auxiliar no tratamento da regra desejada.

Importante: Toda criação e manutenção de tabelas deve ser realizada exclusivamente pelas ferramentas disponibilizadas no módulo Configurador, bem como, toda manipulação de dados nas tabelas, exclusivamente via processamento. Não se recomenda quaisquer procedimentos diretamente no banco de dados.

No caso de criação de novos campos por parte da TOTVS, os mesmos serão adicionados na tabela através do UPDDISTR, podendo assim ultrapassar o limite de 350, tornando a tabela indisponível para criação de novos campos customizados.


Porque há o limite de campos?

Trabalhar com tabelas muito largas (350+ colunas) em SQL Server, Oracle e PostgreSQL traz problemas que impacta no armazenamento, performance, manutenção e até limites físicos dos SGBDs.
Segue um panorama por categoria e por banco:


Problemas práticos e de performance

a) Tamanho da linha e overflow

  • Se a soma das colunas fixas ultrapassa o tamanho de página/bloco, o SGBD precisa armazenar parte da linha em estruturas externas (row-overflow no SQL Server, TOAST no PostgreSQL, out-of-line LOBs no Oracle).

  • Isso aumenta I/O porque cada leitura pode gerar acesso extra ao disco.

  • Linhas grandes ⇒ menos linhas por página ⇒ menos dados no cache ⇒ mais page reads.

b) Índices mais pesados

  • Índices compostos com muitas colunas ficam enormes e afetam:

    • Tempo de manutenção de índices (INSERT/UPDATE/DELETE)

    • Uso de memória no cache

    • Tempo de reconstrução/reorganização.

  • Em alguns casos, o otimizador pode evitar o índice porque o custo de leitura é alto.

c) Impacto no lock e concorrência

  • Linhas maiores ⇒ menos linhas por página ⇒ lock escalation mais rápida (especialmente no SQL Server).

d) Problemas de manutenção e modelagem

  • Mais colunas ⇒ maior acoplamento da tabela.

  • Dificulta evoluções de schema.

  • Queries ficam enormes, dificultando a legibilidade e otimização.

  • Aumenta risco de colunas “mortas” ou não utilizadas ocuparem espaço à toa.

e) Backup e restore mais lentos

  • Linhas grandes ⇒ tabelas ocupam mais espaço no datafile.

  • Mais dados para ler/gravar durante backup/restauração.

f) Custo de transferência

  • SELECT * em tabelas largas é desastroso para rede e para o cliente, mesmo que poucas colunas sejam usadas.

Pontos específicos por banco

SQL Server

  • Limite de 8.060 bytes para colunas fixas (tipos como char, int, decimal com precisão alta).

  • Colunas que estouram vão para row-overflow, que é mais lento.

  • ALTER TABLE para adicionar/remover colunas em tabelas grandes pode gerar rebuild pesado.

Oracle

  • Atualizações em colunas LOB/CLOB em tabelas largas podem gerar chaining de linhas.

  • Algumas features de compressão de tabela funcionam pior com tabelas extremamente largas.

  • Export/Import com DataPump pode ser mais demorado e consumir mais memória no buffer.

PostgreSQL

  • Linhas grandes podem ficar espalhadas em várias páginas (tuple chaining), piorando leituras sequenciais.

  • Tabelas largas com UPDATE frequente causam bloat mais rápido, exigindo VACUUM mais constante.

  • Sem rótulos