Há um debate no trabalho de minha esposa sobre apenas usar varchar(255)
para todos os varchar
campos em tabelas temporárias em procedimentos armazenados. Basicamente, um campo deseja usar 255 porque sempre funcionará mesmo se a definição mudar, e o outro campo deseja manter o tamanho nas tabelas de origem para possíveis melhorias de desempenho.
O acampamento de desempenho está certo? Existem outras implicações? Eles estão usando o SQL Server.
Dependendo de como você está usando suas tabelas temporárias, pode ocorrer um problema de truncamento de dados.
Este exemplo é um pouco artificial, mas ilustra o meu ponto. Exemplo:
A tabela temporária aceitaria de bom grado o novo valor varchar com um comprimento de 59. No entanto, sua tabela de usuário não poderia. Dependendo de como você lida com isso em seu procedimento, isso pode resultar em truncamento ou erro.
A menos que você documente e considere esses problemas, seu procedimento pode ser executado de maneira inesperada.
Pessoalmente, não acho que haja uma resposta para essa pergunta que seja correta 100% das vezes. Realmente depende de como você está usando essas tabelas temporárias.
Espero que isto ajude
Eu me inclinaria para o uso do comprimento real do campo.
Eu li recentemente que as tabelas temporárias do MySQL (suponho que o SQL Server seja semelhante) alocam memória suficiente para armazenar o comprimento máximo possível para cada
varchar
coluna ... Uma abordagem sistemática para alocar 200%-500% da memória necessária paravarchar
campos em todos procedimentos armazenados parecem um consumo desnecessário de recursos do sistema. Se você estiver usando uma quantidade significativa de memória criando essas tabelas temporárias, poderá estar reivindicando desnecessariamente a memória que estava em uso para armazenamento em cache, criando mais trabalho para o servidor em algum momento no futuro, mesmo após a conclusão dos procedimentos de armazenamento.Editar: Veja a resposta de Bill Karwin: https://stackoverflow.com/questions/1962310/importance-of-varchar-length-in-mysql-table