exagerando o tamanho do campo no design do banco de dados

Eu tenho alguns campos para minhas tabelas que são seqüências de caracteres e, no momento, a maior parte do tamanho do campo tem limites de caracteres bastante altos. Por exemplo, 100 caracteres para o nome da rua. Existe uma penalidade por usar um tamanho de campo grande? Se eu alterar o limite para 30 caracteres para este campo, por exemplo, haverá um ganho de desempenho ou uma eficiência no tamanho? Havia cerca de 50 campos que poderiam ser candidatos ao encolhimento.

Obrigado por suas sugestões.

Se você está falando varchare nvarcharentão não, não há penalidade por permitir um tamanho de campo maior.

Algumas advertências a serem lembradas:

• Há uma sobrecarga de 2 bytes por linha para campos de comprimento variável (por campo). Se você tem um campo muito curto, pode fazer mais sentido usar a CHAR. Varchar(2)por exemplo, na verdade, usa entre 2 a 4 bytes por linha, enquanto CHAR(2)sempre usa 2.
• Campos muito longos não podem ser indexados. O comprimento máximo para todos os campos em um conjunto de chaves de índice é de 900 bytes.
• Se você permitir mais dados do que o esperado, obterá resultados inesperados. Se você permitir 100 caracteres para um nome de rua, em algum momento é provável que outros dados entrem nesse campo sem que você esteja ciente (por exemplo, o endereço inteiro). Se você o tivesse dimensionado adequadamente, provavelmente haveria um erro ao inserir.
• Permitir linhas muito largas pode levar a divisões e fragmentação de páginas. Se você tiver uma linha com mais de 8k, precisará ser dividida em várias páginas de dados. Muitos deles podem realmente prejudicar o desempenho. Mais estreito, em geral, é mais eficiente.

Se você quer dizer: "Existe uma penalidade por declarar o tamanho do campo maior que qualquer valor que realmente esteja armazenado nele?", Desde que seja declarado varchar, a resposta é não. Todo mecanismo de banco de dados SQL que eu conheço armazena apenas o número de caracteres realmente fornecido nos dados (mais um valor de comprimento). Portanto, se você definir o campo como varchar (100), mas armazenar apenas 10 caracteres, ele ocupará apenas 10 caracteres no disco (mais 2 bytes ou mais para o comprimento). Em caso de dúvida, rotineiramente faço meus campos varchar ridiculamente grandes.

Se você quer dizer "Existe uma penalidade para armazenar campos de caracteres longos", a resposta é sim. Hoje, o espaço em disco é barato, mas não é gratuito; portanto, você não deseja desperdiçá-lo sem motivo. Provavelmente mais importante, leva tempo para ler os dados do disco; portanto, quanto mais longos os campos de dados, mais lento o programa se torna. Se o campo estiver indexado, isso pode realmente atrasar suas recuperações, pois todas as leituras terão que comparar o valor da chave com esse grande e longo campo.

Lembre-se de que, se você fornecer ao usuário um campo de entrada de grande volume de dados, ele o usará, mais cedo ou mais tarde.

Tudo isso dito, eu errei por ser muito grande, e não muito pequena. O espaço em disco é barato o suficiente para que você não queira forçar os usuários a inventar abreviações rapidamente, porque eles não podem ajustar os dados reais no campo disponível. O sistema em que estou trabalhando hoje tem um campo de descrição do produto que é muito pequeno para muitos dos nomes reais de nossos produtos, portanto, os usuários precisam abreviar. E, é claro, todos os usuários abreviam de maneira diferente, por isso temos vinte maneiras diferentes de dizer a mesma coisa.

Qualquer pessoa que afirme que não há penalidade por declarar um tamanho de campo maior do que o que realmente será armazenado na tabela está incorreta. O tamanho real dos dados (mais a sobrecarga de 2 bytes) é o que realmente é armazenado, mas é a definição de coluna usada para determinar a estimativa até o plano de execução. Portanto, embora declarar um varchar (1000) para armazenar um valor de 10 caracteres consuma apenas 12 caracteres de espaço em disco, as estimativas do plano de execução serão muito menos eficientes e distorcerão os resultados, tanto quanto de memória para conceder a operação e se a operação pode ou não ser executada apenas na memória ou se também requer espaço em disco tempdb. Você pode criar sua coluna varchar (1000), mas o mecanismo não sabe que todos os seus valores armazenados são realmente menores que varchar (10),

A verificação do tamanho do campo é algo que você obtém 'de graça', o que significa que você não precisa usar uma CHECKrestrição para fazer o mesmo. E você não deseja valores de dados superdimensionados quando, por exemplo, precisar carregar seus dados em outro banco de dados que limitou o mesmo elemento de dados a 35 caracteres, de acordo com o endereço padrão internacional.