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
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
Tabelas largas com UPDATE frequente causam bloat mais rápido, exigindo VACUUM mais constante.