Como varchar ocupa espaço em disco proporcional ao tamanho do campo, existe alguma razão para não definirmos sempre varchar como o máximo, por exemplo, varchar(8000)no SQL Server?
Na mesa de criação, se eu vir alguém fazendo varchar(100)isso, devo dizer a eles que não, você está errado, você deve fazer varchar(8000)?
Resumo: não faça isso.
Supondo que você esteja se referindo ao SQL Server, posso pensar em um.
Há um limite para o tamanho (8K) de uma linha em uma tabela e o SQL permite definir campos varchar que teoricamente podem exceder esse limite. Assim, o usuário pode obter erros se colocar muitos dados no campo relacionado a isso.
A partir do SQL 2K8, você pode exceder esse limite, mas há implicações de desempenho .
Além disso, há toda a verificação de razoabilidade de limitar o tamanho ao que você espera que os dados tenham. Se você deseja um campo de comprimento ilimitado, por que não usar text ou ntext?
Certamente depende de quais informações estão sendo armazenadas no campo?
Algumas coisas terão um comprimento máximo por vários motivos e, se tiver que haver um comprimento máximo, esse deve ser o comprimento do seu campo.
Se teoricamente não houver comprimento máximo, eu questionaria por que varchar seria usado.
No contexto dos bancos de dados Oracle, aprendi que sempre usar o menor tamanho de campo para as colunas do banco de dados tem uma armadilha.
Ao mover dados por meio de exportação de importação de um banco de dados com agrupamento de byte único para um com agrupamento de byte múltiplo (como Oracle XE), o comprimento em bytes pode aumentar e importar os dados para as tabelas criadas por importação falha. É claro que o Oracle tem a opção de definir o comprimento de varchar2 como char ou como byte.
Meu ponto aqui é que nem sempre é sábio definir o campo sempre com o menor possível. Eu vi muitas tabelas alteradas para aumentar o campo posteriormente (causadas por requisitos alterados).
Ter 20% - 100% de campo não utilizado é uma opção discutível aqui.